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[57] 



ABSTRACT 



(List continued on next page.) 



The present invention provides systems and methods for 
electronic commerce including secure transaction manage- 
ment and electronic rights protection. Electronic appliances 
such as computers employed in accordance with the present 
invention help to ensure that information is accessed and 
used only in authorized ways, and maintain the integrity, 
availability, and/or confidentiality of the information. Secure 
subsystems used with such electronic appliances provide a 
distributed virtual distribution environment (VDE) that may 
enforce a secure chain of handling and control, for example, 
to control and/or meter or otherwise monitor use of elec- 
tronically stored or disseminated information. Such a virtual 
distribution environment may be used to protect rights of 
various participants in electronic commerce and other elec- 
tronic or electronic-facilitated transactions. Secure distrib- 
uted and other operating system environments and 
architectures, employing, for example, secure semiconduc- 
tor processing arrangements that may establish secure, pro- 
tected environments at each node. These techniques may be 
used to support an end-to-end electronic information distri- 
bution capability that may be used, for example, utilizing the 
"electronic highway." 

220 Claims, 163 Drawing Sheets 
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SYSTEMS AND METHODS FOR SECURE 
TRANSACTION MANAGEMENT AND 
ELECTRONIC RIGHTS PROTECTION 

FIELD(S) OF THE INVENTIONS) 

This invention generally relates to computer and/or elec- 
tronic security. 

More particularly, this invention relates to systems and 
techniques for secure transaction management. This inven- 
tion also relates to computer-based and other electronic 
appliance-based technologies that help to ensure that infor- 
mation is accessed and/or otherwise used only in authorized 
ways, and maintains the integrity, availability, and/or con- 
fidentiality of such information and processes related to such 
use. 

The invention also relates to systems and methods for 
protecting rights of various participants in electronic com- 
merce and other electronic or electronically-facilitated trans- 
actions. 

The invention also relates to secure chains of handling 
and control for both information content and information 
employed to regulate the use of such content and conse- 
quences of such use. It also relates to systems and techniques 
that manage, including meter and/or limit and/or otherwise 
monitor use of electronically stored and/or disseminated 
information. The invention particularly relates to 
transactions, conduct and arrangements that make use of, 
including consequences of use of, such systems and/or 
techniques. 

The invention also relates to distributed and other oper- 
ating systems, environments and architectures. It also gen- 
erally relates to secure architectures, including, for example, 
tamper-resistant hardware-based processors, that can be 
used to establish security at each node of a distributed 
system. 

BACKGROUND AND SUMMARY OF THE 
INVENTION(S) 

Telecommunications, financial transactions, government 
processes, business operations, entertainment, and personal 
business productivity all now depend on electronic appli- 
ances. Millions of these electronic appliances have been 
electronically connected together. These interconnected 
electronic appliances comprise what is increasingly called 
the "information highway/' Many businesses, academicians, 
and government leaders are concerned about how to protect 
the rights of citizens and organizations who use this infor- 
mation (also "electronic" or "digital") highway. 

Electronic Content 

Today, virtually anything that can be represented by 
words, numbers, graphics, or system of commands and 
instructions can be formatted into electronic digital infor- 
mation. Television, cable, satellite transmissions, and 
on-line services transmitted over telephone lines, compete to 
distribute digital information and entertainment to homes 
and businesses. The owners and marketers of this content 
include software developers, motion picture and recording 
companies, publishers of books, magazines, and 
newspapers, and information database providers. The popu- 
larization of on-line services has also enabled the individual 
personal computer user to participate as a content provider. 
It is estimated that the worldwide market for electronic 
information in 1992 was approximately $40 billion and is 
expected to grow to $200 billion by 1997, according to 
Microsoft Corporation. The present invention can materially 



)2,900 

2 

enhance the revenue of content providers, lower the distri- 
bution costs and the costs for content, better support adver- 
tising and usage information gathering, and better satisfy the 
needs of electronic information users. These improvements 

5 can lead to a significant increase in the amount and variety 
of electronic information and the methods by which such 
information is distributed. 

The inability of conventional products to be shaped to the 
needs of electronic information providers and users is 

10 sharply in contrast to the present invention. Despite the 
attention devoted by a cross-section of America's largest 
telecommunications, computer, entertainment and informa- 
tion provider companies to some of the problems addressed 
by the present invention, only the present invention provides 

15 commercially secure, effective solutions for configurable, 
general purpose electronic commerce transaction/ 
distribution control systems. 
Controlling Electronic Content 

20 The present invention provides a new kind of "virtual 
distribution environment" (called "VDE" in this document) 
that secures, administers, and audits electronic information 
use. VDE also features fundamentally important capabilities 
for managing content that travels "across" the "information 

^ highway." These capabilities comprise a rights protection 
solution that serves all electronic community members. 
These members include content creators and distributors, 
financial service providers, end-users, and others. VDE is 
the first general purpose, configurable, transaction control/ 

30 rights protection solution for users of computers, other 
electronic appliances, networks, and the information high- 
way. 

A fundamental problem for electronic content providers is 
extending their ability to control the use of proprietary 

35 information. Content providers often need to limit use to 
authorized activities and amounts. Participants in a business 
model involving, for example, provision of movies and 
advertising on optical discs may include actors, directors, 
script and other writers, musicians, studios, publishers, 

40 distributors, retailers, advertisers, credit card services, and 
content end-users. These participants need the ability to 
embody their range of agreements and requirements, includ- 
ing use limitations, into an "extended" agreement compris- 
ing an overall electronic business model. This extended 

45 agreement is represented by electronic content control infor- 
mation that can automatically enforce agreed upon rights 
and obligations. Under VDE, such an extended agreement 
may comprise an electronic contract involving all business 
model participants. Such an agreement may alternatively, or 

50 in addition, be made up of electronic agreements between 
subsets of the business model participants. Through the use 
of VDE, electronic commerce can function in the same way 
as traditional commerce — that is commercial relationships 
regarding products and services can be shaped through the 

55 negotiation of one or more agreements between a variety of 
parties. 

Commercial content providers are concerned with ensur- 
ing proper compensation for the use of their electronic 
information. Electronic digital information, for example a 

60 CD recording, can today be copied relatively easily and 
inexpensively. Similarly, unauthorized copying and use of 
software programs deprives rightful owners of billions of 
dollars in annual revenue according to the International 
Intellectual Property Alliance. Content providers and dis- 

65 tributors have devised a number of limited function rights 
protection mechanisms to protect their rights. Authorization 
passwords and protocols, license servers, "lock/unlock" 
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distribution methods, and non -electronic contractual limita- 
tions imposed on users of shrink-wrapped software are a few 
of the more prevalent content protection schemes. In a 
commercial context, these efforts are inefficient and limited 
solutions. 5 

Providers of "electronic currency'* have also created pro- 
tections for their type of content. These systems are not 
sufficiently adaptable, efficient, nor flexible enough to sup- 
port the generalized use of electronic currency. Furthermore, 
they do not provide sophisticated auditing and control 10 
configuration capabilities. This means that current electronic 
currency tools lack the sophistication needed for many 
real-world financial business models. VDE provides means 
for anonymous currency and for "conditionally" anonymous 
currency, wherein currency related activities remain anony- 15 
mous except under special circumstances. 

VDE Control Capabilities 

VDE allows the owners and distributors of electronic 
digital information to reliably bill for, and securely control, 
audit, and budget the use of, electronic information. It can 20 
, reliably detect and monitor the use of commercial informa- 
tion products. VDE uses a wide variety of different elec- 
tronic information delivery means: including, for example, 
digital networks, digital broadcast, and physical storage 
media such as optical and magnetic disks. VDE can be used 25 
by major network providers, hardware manufacturers, own- 
ers of electronic information, providers of such information, 
and clearinghouses that gather usage information regarding, 
and bill for the use of, electronic information. 

VDE provides comprehensive and configurable transac- 
tion management, metering and monitoring technology. It 
can change how electronic information products are 
protected, marketed, packaged, and distributed. When used, 
VDE should result in higher revenues for information pro- ^ 
viders and greater user satisfaction and value. Use of VDE 
will normally result in lower usage costs, decreased trans- 
action costs, more efficient access to electronic information, 
re-usability of rights protection and other transaction man- 
agement implementations, greatly improved flexibility in the 4Q 
use of secured information, and greater standardization of 4 
tools and processes for electronic transaction management. 
VDE can be used to create an adaptable environment that 
fulfills the needs of electronic information owners, 
distributors, and users; financial clearinghouses; and usage 
information analyzers and resellers. 

Rights and Control Information 

In general, the present invention can be used to protect the 
rights of parties who have: 

(a) proprietary or confidentiality interests in electronic 50 
information, It can, for example, help ensure that 
information is used only in authorized ways; 

(b) financial interests resulting from the use of electroni- 
cally distributed information. It can help ensure that 
content providers will be paid for use of distributed 55 
information; and 

(c) interests in electronic credit and electronic currency 
storage, communication, and/or use including elec- 
tronic cash, banking, and purchasing. 

Protecting the rights of electronic community members 60 
involves a broad range of technologies. VDE combines these 
technologies in a way that creates a "distributed" electronic 
rights protection "environment." This environment secures 
and protects transactions and other processes important for 
rights protection. VDE, for example, provides the ability to 65 
prevent, or impede, interference with and/or observation of, 
important rights related transactions and processes. VDE, in 
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its preferred embodiment, uses special purpose tamper resis- 
tant Secure Processing Units (SPUs) to help provide a high 
level of security for VDE processes and information storage 
and communication. 

The rights protection problems solved by the present 
invention are electronic versions of basic societal issues. 
These issues include protecting property rights, protecting 
privacy rights, properly compensating people and organiza- 
tions for their work and risk, protecting money and credit, 
and generally protecting the security of information. VDE 
employs a system that uses a common set of processes to 
manage rights issues in an efficient, trusted, and cost- 
effective way. 

VDE can be used to protect the rights of parties who 
create electronic content such as, for example: records, 
games, movies, newspapers, electronic books and reference 
materials, personal electronic mail, and confidential records 
and communications. The invention can also be used to 
protect the rights of parties who provide electronic products, 
such as publishers and distributors; the rights of parties who 
provide electronic credit and currency to pay for use of 
products, for example, credit clearinghouses and banks; the 
rights to privacy of parties who use electronic content (such 
as consumers, business people, governments); and the pri- 
vacy rights of parties described by electronic information, 
such as privacy rights related to information contained in a 
medical record, tax record, or personnel record. 

In general, the present invention can protect the rights of 
parties who have: 

(a) commercial interests in electronically distributed 
information — the present invention can help ensure, for 
example, that parties, will be paid for use of distributed 
information in a manner consistent with their agree- 
ment; 

(b) proprietary and/or confidentiality interests in elec- 
tronic information — the present invention can, for 
example, help ensure that data is used only in autho- 
rized ways; 

(c) interests in electronic credit and electronic currency 
storage, communication, and/or use — this can include 
electronic cash, banking, and purchasing; and 

(d) interests in electronic information derived, at least in 
part, from use of other electronic information. 

VDE Functional Properties 

VDE is a cost-effective and efficient rights protection 
solution that provides a unified, consistent system for secur- 
ing and managing transaction processing. VDE can: 

(a) audit and analyze the use of content, 

(b) ensure that content is used only in authorized ways, 
and 

(c) allow information regarding content usage to be used 
only in ways approved by content users. 

In addition, VDE: 

(a) is very configurable, modifiable, and re-usable; 

(b) supports a wide range of useful capabilities that may 
be combined in different ways to accommodate most 
potential applications; 

(c) operates on a wide variety of electronic appliances 
ranging from hand-held inexpensive devices to large 
mainframe computers; 

(d) is able to ensure the various rights of a number of 
different parties, and a number of different rights pro- 
tection schemes, simultaneously; 

(e) is able to preserve the rights of parties through a series 
of transactions that may occur at different times and 
different locations; 
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(f) is able to flexibly accommodate different ways of 
securely delivering information and reporting usage; 
and 

(g) provides for electronic analogues to "real** money and 
credit, including anonymous electronic cash, to pay for 5 
products and services and to support personal 
(including home) banking and other financial activities. 

VDE economically and efficiently fulfills the rights pro- 
tection needs of electronic community members. Users of 
VDE will not require additional rights protection systems for io 
different information highway products and rights 
problems — nor will they be required to install and learn a 
new system for each new information highway application. 

VDE provides a unified solution that allows all content 
creators, providers, and users to employ the same electronic 
rights protection solution. Under authorized circumstances, 
the participants can freely exchange content and associated 
content control sets. This means that a user of VDE may, if 
allowed, use the same electronic system to work with 
different kinds of content having different sets of content 20 
control information. The content and control information 
supplied by one group can be used by people who normally 
use content and control information supplied by a different 
group. VDE can allow content to be exchanged "univer- 
sally" and users of an implementation of the present inven- 25 
tion can interact electronically without fear of incompat- 
ibilities in content control, violation of rights, or the need to 
get, install, or learn a new content control system. 

The VDE securely administers transactions that specify 
protection of rights. It can protect electronic rights 30 
including, for example: 

(a) the property rights of authors of electronic content, 

(b) the commercial rights of distributors of content, 

(c) the rights of any parties who facilitated the distribution 35 
of content, 

(d) the privacy rights of users of content, 

(e) the privacy rights of parties portrayed by stored and/or 
distributed content, and 

(f) any other rights regarding enforcement of electronic 40 
agreements 

VDE can enable a very broad variety of electronically 
enforced commercial and societal agreements. These agree- 
ments can include electronically implemented contracts, 
licenses, laws, regulations, and tax collection. 45 

Contrast With Traditional Solutions 

Traditional content control mechanisms often require 
users to purchase more electronic information than the user 
needs or desires. For example, infrequent users of shrink- 
wrapped software are required to purchase a program at the 50 
same price as frequent users, even though they may receive 
much less value from their less frequent use. Traditional 
systems do not scale cost according to the extent or character 
of usage and traditional systems can not attract potential 
customers who find that a fixed price is too high. Systems 55 
using traditional mechanisms are also not normally particu- 
larly secure. For example, shrink-wrapping does not prevent 
the constant illegal pirating of software once removed from 
either its physical or electronic package. 

Traditional electronic information rights protection sys- 60 
terns are often inflexible and inefficient and may cause a 
content provider to choose costly distribution channels that 
increase a product's price. In general these mechanisms 
restrict product pricing, configuration, and marketing flex- 
ibility. These compromises are the result of techniques for 65 
controlling information which cannot accommodate both 
different content models and content models which reflect 
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the many, varied requirements, such as content delivery 
strategies, of the model participants. This can limit a pro- 
vider's ability to deliver sufficient overall value to justify a 
given product's cost in the eyes of many potential users. 
VDE allows content providers and distributors to create 
applications and distribution networks that reflect content 
providers* and users' preferred business models. It offers 
users a uniquely cost effective and feature rich system that 
supports the ways providers want to distribute information 
and the ways users want to use such information. VDE 
supports content control models that ensure rights and allow 
content delivery strategies to be shaped for maximum com- 
mercial results. 

Chain of Handling and Control 

VDE can protect a collection of rights belonging to 
various parties having in rights in, or to, electronic infor- 
mation. This information may be at one location or dispersed 
across (and/or moving between) multiple locations. The 
information may pass through a "chain" of distributors and 
a "chain" of users. Usage information may also be reported 
through one or more "chains" of parties. In general, VDE 
enables parties that (a) have rights in electronic information, 
and/or (b) act as direct or indirect agents for parties who 
have rights in electronic information, to ensure that the 
moving, accessing, modifying, or otherwise using of infor- 
mation can be securely controlled by rules regarding how, 
when, where, and by whom such activities can be per- 
formed. 

VDE Applications and Software 

VDE is a secure system for regulating electronic conduct 
and commerce. Regulation is ensured by control information 
put in place by one or more parties. These parties may 
include content providers, electronic hardware 
manufacturers, financial service providers, or electronic 
"infrastructure" companies such as cable or telecommuni- 
cations companies. The control information implements 
"Rights Applications." Rights applications "run on" the 
"base software" of the preferred embodiment. This base 
software serves as a secure, flexible, general purpose foun- 
dation that can accommodate many different rights 
applications, that is, many different business models and 
their respective participant requirements. 

A rights application under VDE is made up of special 
purpose pieces, each of which can correspond to one or more 
basic electronic processes needed for a rights protection 
environment. These processes can be combined together like 
building blocks to create electronic agreements that can 
protect the rights, and may enforce fulfillment of the 
obligations, of electronic information users and providers. 
One or more providers of electronic information can easily 
combine selected building blocks to create a rights applica- 
tion that is unique to a specific content distribution model. 
A group of these pieces can represent the capabilities needed 
to fulfill the agreements) between users and providers. 
These pieces accommodate many requirements of electronic 
commerce including: 

the distribution of permissions to use electronic informa- 
tion; 

the persistence of the control information and sets of 
control information managing these permissions; 

configurable control set information that can be selected 
by users for use with such information; 

data security and usage auditing of electronic information; 
and 

a secure system for currency, compensation and debit 
management. 
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For electronic commerce, a rights application, under the 
preferred embodiment of the present invention, can provide 
electronic enforcement of the business agreements between 
all participants. Since different groups of components can be 
put together for different applications, the present invention 
can provide electronic control information for a wide variety 
of different products and markets. This means the present 
invention can provide a "unified," efficient, secure, and 
cost-effective system for electronic commerce and data 
security. This allows VDE to serve as a single standard for 
electronic rights protection, data security, and electronic 
currency and banking. 

In a VDE, the separation between a rights application and 
its foundation permits the efficient selection of sets of 
control information that are appropriate for each of many 
different types of applications and uses. These control sets 
can reflect both rights of electronic community members, as 
well as obligations (such as providing a history of one's use 
of a product or paying taxes on one's electronic purchases) 
VDE flexibility allows its users to electronically implement 
and enforce common social and commercial ethics and 
practices. By providing a unified control system, the present 
invention supports a vast range of possible transaction 
related interests and concerns of individuals, communities, 
businesses, and governments. Due to its open design, VDE 
allows (normally under securely controlled circumstances) 
applications using technology independently created by 
users to be "added" to the system and used in conjunction 
with the foundation of the invention. In sum, VDE provides 
a system that can fairly reflect and enforce agreements 
among parties. It is a broad ranging and systematic solution 
that answers the pressing need for a secure, cost-effective, 
and fair electronic environment. 

VDE Implementation 

The preferred embodiment of the present invention 
includes various tools that enable system designers to 
directly insert VDE capabilities into their products. These 
tools include an Application Programmer's Interface 
("API") and a Rights Permissioning and Management Lan- 
guage ("RPML"). The RPML provides comprehensive and 
detailed control over the use of the invention's features. 
VDE also includes certain user interface subsystems for 
satisfying the needs of content providers, distributors, and 
users. 

Information distributed using VDE may take many forms. 
It may, for example, be "distributed" for use on an individu- 
al's own computer, that is the present invention can be used 
to provide security for locally stored data. Alternatively, 
VDE may be used with information that is dispersed by 
authors and/or publishers to one or more recipients. This 
information may take many forms including: movies, audio 
recordings, games, electronic catalog shopping, multimedia, 
training materials, E-mail and personal documents, object 
oriented libraries, software programming resources, and 
reference/record keeping information resources (such as 
business, medical, legal, scientific, governmental, and con- 
sumer databases). 

Electronic rights protection provided by the present 
invention will also provide an important foundation for 
trusted and efficient home and commercial banking, elec- 
tronic credit processes, electronic purchasing, true or con- 
ditionally anonymous electronic cash, and EDI (Electronic 
Data Interchange). VDE provides important enhancements 
for improving data security in organizations by providing 
"smart" transaction management features that can be far 
more effective than key and password based "go/no go" 
technology. 
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VDE normally employs an integration of cryptographic 
and other security technologies (e.g. encryption, digital 
signatures, etc.), with other technologies including: 
component, distributed, and event driven operating system 
5 technology, and related communications, object container, 
database, smart agent, smart card, and semiconductor design 
technologies. 

I. Overview 

A. VDE Solves Important Problems and Fills Critical 
10 Needs 

The world is moving towards an integration of electronic 
information appliances. This interconnection of appliances 
provides a foundation for much greater electronic interaction 
and the evolution of electronic commerce. A variety of 
15 capabilities are required to implement an electronic com- 
merce environment. VDE is the first system that provides 
many of these capabilities and therefore solves fundamental 
problems related to electronic dissemination of information. 
Electronic Content 
20 VDE allows electronic arrangements to be created involv- 
ing two or more parties. These agreements can themselves 
comprise a collection of agreements between participants in 
a commercial value chain and/or a data security chain model 
for handling, auditing, reporting, and payment. It can pro- 
25 vide efficient, reusable, modifiable, and consistent means for 
secure electronic content: distribution, usage control, usage 
payment, usage auditing, and usage reporting. Content may, 
for example, include: 

financial information such as electronic currency and 
30 credit; 

commercially distributed electronic information such as 
reference databases, movies, games, and advertising; 
and 

electronic properties produced by persons and 
35 organizations, such as documents, e-mail, and propri- 
etary database information. 
VDE enables an electronic commerce marketplace that 
supports differing, competitive business partnerships, 
agreements, and evolving overall business models. 
40 The features of VDE allow it to function as the first trusted 
electronic information control environment that can con- 
form to, and support, the bulk of conventional electronic 
commerce and data security requirements. In particular, 
VDE enables the participants in a business value chain 
45 model to create an electronic version of traditional business 
agreement terms and conditions and further enables these 
participants to shape and evolve their electronic commerce 
models as they believe appropriate to their business require- 
ments. 

50 VDE offers an architecture that avoids reflecting specific 
distribution biases, administrative and control perspectives, 
and content types. Instead, VDE provides a broad-spectrum, 
fundamentally configurable and portable, electronic trans- 
action control, distributing, usage, auditing, reporting, and 

55 payment operating environment. VDE is not limited to being 
an application or application specific toolset that covers only 
a limited subset of electronic interaction activities and 
participants. Rather, VDE supports systems by which such 
applications can be created, modified, and/or reused. As a 

60 result, the present invention answers pressing, unsolved 
needs by offering a system that supports a standardized 
control environment which facilitates interoperability of 
electronic appliances, interoperability of content containers, 
and efficient creation of electronic commerce applications 

65 and models through the use of a programmable, secure 
electronic transactions management foundation and reusable 
and extensible executable components. VDE can support a 
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single electronic "world" within which most forms of elec- 
tronic transaction activities can be managed. 

To answer the developing needs of rights owners and 
content providers and to provide a system that can accom- 
modate the requirements and agreements of all parties that 
may be involved in electronic business models (creators, 
distributors, administrators, users, credit providers, etc.), 
VDE supplies an efficient, largely transparent, low cost and 
sufficiently secure system (supporting both hardware/ 
software and software only models). VDE provides the 
widely varying secure control and administration capabili- 
ties required for: 

1. Different types of electronic content, 

2. Differing electronic content delivery schemes, 

3. Differing electronic content usage schemes, 

4. Different content usage platforms, and 

5. Differing content marketing and model strategies. 
VDE may be combined with, or integrated into, many 

separate computers and/or other electronic appliances. 
These appliances typically include a secure subsystem that 
can enable control of content use such as displaying, 
encrypting, decrypting, printing, copying, saving, 
extracting, embedding, distributing, auditing usage, etc. The 
secure subsystem in the preferred embodiment comprises 
one or more "protected processing environments", one or 
more secure databases, and secure "component assemblies" 
and other items and processes that need to be kept secured. 
VDE can, for example, securely control electronic currency, 
payments, and/or credit management (including electronic 
credit and/or currency receipt, disbursement, encumbering, 
and/or allocation) using such a "secure subsystem." 

VDE provides a secure, distributed electronic transaction 
management system for controlling the distribution and/or 
other usage of electronically provided and/or stored infor- 
mation. VDE controls auditing and reporting of electronic 
content and/or appliance usage. Users of VDE may include 
content creators who apply content usage, usage reporting, 
and/or usage payment related control information to elec- 
tronic content and/or appliances for users such as end-user 
organizations, individuals, and content and/or appliance 
distributors. VDE also securely supports the payment of 
money owed (including money owed for content and/or 
appliance usage) by one or more parlies to one or more other 
parties, in the form of electronic credit and/or currency. 

Electronic appliances under control of VDE represent 
VDE 'nodes' that securely process and control; distributed 
electronic information and/or appliance usage, control infor- 
mation formulation, and related transactions. VDE can 
securely manage the integration of control information pro- 
vided by two or more parties. As a result, VDE can construct 
an electronic agreement between VDE participants that 
represent a "negotiation" between, the control requirements 
of, two or more parties and enacts terms and conditions of 
a resulting agreement. VDE ensures the rights of each party 
to an electronic agreement regarding a wide range of elec- 
tronic activities related to electronic information and/or 
appliance usage. 

Through use of VDE's control system, traditional content 
providers and users can create electronic relationships that 
reflect traditional, non-electronic relationships. They can 
shape and modify commercial relationships to accommodate 
the evolving needs of, and agreements among, themselves. 
VDE does not require electronic content providers and users 
to modify their business practices and personal preferences 
to conform to a metering and control application program 
that supports limited, largely fixed functionality. 
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Furthermore, VDE permits participants to develop business 
models not feasible with non-electronic commerce, for 
example, involving detailed reporting of content usage 
information, large numbers of distinct transactions at hith- 

5 erto infeasibly low price points, "pass-along" control infor- 
mation that is enforced without involvement or advance 
knowledge of the participants, etc. 

The present invention allows content providers and users 
to formulate their transaction environment to accommodate: 

10 (1) desired content models, content control models, and 
content usage information pathways, 

(2) a complete range of electronic media and distribution 
means, 

(3) a broad range of pricing, payment, and auditing 
15 strategies, 

(4) very flexible privacy and/or reporting models, 

(5) practical and effective security architectures, and 

(6) other administrative procedures that together with 
20 steps (1) through (5) can enable most "real world" 

electronic commerce and data security models, includ- 
ing models unique to the electronic world. 
VDE's transaction management capabilities can enforce: 

(1) privacy rights of users related to information regarding 
25 their usage of electronic information and/or appliances, 

(2) societal policy such as laws that protect rights of 
content users or require the collection of taxes derived 
from electronic transaction revenue, and 

(3) the proprietary and/or other rights of parties related to 
30 ownership of, distribution of, and/or other commercial 

rights related to, electronic information. 
VDE can support "real" commerce in an electronic form, 
that is the progressive creation of commercial relationships 
that form, over time, a network of interrelated agreements 

35 representing a value chain business model. This is achieved 
in part by enabling content control information to develop 
through the interaction of (negotiation between) securely 
created and independently submitted sets of content and/or 
appliance control information. Different sets of content 

40 and/or appliance control information can be submitted by 
different parties in an electronic business value chain 
enabled by the present invention. These parties create con- 
trol information sets through the use of their respective VDE 
installations. Independently, securely deliverable, compo- 

45 nent based control information allows efficient interaction 
among control information sets supplied by different parties. 

VDE permits multiple, separate electronic arrangements 
to be formed between subsets of parties in a VDE supported 
electronic value chain model. These multiple agreements 

50 together comprise a VDE value chain "extended" agree- 
ment. VDE allows such constituent electronic agreements, 
and therefore overall VDE extended agreements, to evolve 
and reshape over time as additional VDE participants 
become involved in VDE content and/or appliance control 

55 information handling. VDE electronic agreements may also 
be extended as new control information is submitted by 
existing participants. With VDE, electronic commerce par- 
ticipants are free to structure and restructure their electronic 
commerce business activities and relationships. As a result, 

60 the present invention allows a competitive electronic com- 
merce marketplace to develop since the use of VDE enables 
different, widely varying business models using the same or 
shared content. 
A significant facet of the present invention's ability to 

65 broadly support electronic commerce is its ability to 
securely manage independently delivered VDE component 
objects containing control information (normally in the form 
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of VDE objects containing one or more methods, data, or 
load module VDE components). This independently deliv- 
ered control information can be integrated with senior and 
other pre-existing content control information to securely 
form derived control information using the negotiation 
mechanisms of the present invention. All requirements 
specified by this derived control information must be satis- 
fied before VDE controlled content can be accessed or 
otherwise used. This means that, for example, all load 
modules and any mediating data which are listed by the 
derived control information as required must be available 
and securely perform their required function. In combination 
with other aspects of the present invention, securely, inde- 
pendently delivered control components allow electronic 
commerce participants to freely stipulate their business 
requirements and trade ofls. As a result, much as with 
traditional, non-electronic commerce, the present invention 
allows electronic commerce (through a progressive stipula- 
tion of various control requirements by VDE participants) to 
evolve into forms of business that are the most efficient, 
competitive and useful. 

VDE provides capabilities that rationalize the support of 
electronic commerce and electronic transaction manage- 
ment. This rationalization stems from the reusability of 
control structures and user interfaces for a wide variety of 25 
transaction management related activities. As a result, con- 
tent usage control, data security, information auditing, and 
electronic financial activities, can be supported with tools 
that are reusable, convenient, consistent, and familiar. In 
addition, a rational approach — a transaction/distribution 
control standard — allows all participants in VDE the same 
foundation set of hardware control and security, authoring, 
administration, and management tools to support widely 
varying types of information, business market model, and/or 
personal objectives. 

Employing VDE as a general purpose electronic 
transaction/distribution control system allows users to main- 
tain a single transaction management control arrangement 
on each of their computers, networks, communication 
nodes, and/or other electronic appliances. Such a general 
purpose system can serve the needs of many electronic 
transaction management applications without requiring 
distinct, different installations for different purposes. As a 
result, users of VDE can avoid the confusion and expense 
and other inefficiencies of different, limited purpose trans- 
action control applications for each different content and/or 
business model. For example, VDE allows content creators 
to use the same VDE foundation control arrangement for 
both content authoring and for licensing content from other 
content creators for inclusion into their products or for other 
use. Clearinghouses, distributors, content creators, and other 
VDE users can all interact, both with the applications 
running on their VDE installations, and with each other, in 
an entirely consistent manner, using and reusing (largely 
transparently) the same distributed tools, mechanisms, and 
consistent user interfaces, regardless of the type of VDE 
activity. 

VDE prevents many forms of unauthorized use of elec- 
tronic information, by controlling and auditing (and other 
administration of use) electronically stored and/or dissemi- 
nated information. This includes, for example, commercially 
distributed content, electronic currency, electronic credit, 
business transactions (such as EDI), confidential 
communications, and the like. VDE can further be used to 
enable commercially provided electronic content to be made 
available to users in user defined portions, rather than 
constraining the user to use portions of content that were 
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"predetermined" by a content creator and/or other provider 
for billing purposes. 

VDE, for example, can employ: 

(1) Secure metering means for budgeting and/or auditing 
electronic content and/or appliance usage; 

(2) Secure flexible means for enabling compensation 
and/or billing rates for content and/or appliance usage, 
including electronic credit and/or currency mechanisms 
for payment means; 

(3) Secure distributed database means for storing control 
and usage related information (and employing vali- 
dated compartmentalization and tagging schemes); 

(4) Secure electronic appliance control means; 

(5) A distributed, secure, "virtual black box" comprised of 
nodes located at every user (including VDE content 
container creators, other content providers, client users, 
and recipients of secure VDE content usage 
information) site. The nodes of said virtual black box 
normally include a secure subsystem having at least 
one secure hardware element (a semiconductor element 
or other hardware module for securely executing VDE 
control processes), said secure subsystems being dis- 
tributed at nodes along a pathway of information 
storage, distribution, payment, usage, and/or auditing. 
In some embodiments, the functions of said hardware 
element, for certain or all nodes, may be performed by 
software, for example, in host processing environments 
of electronic appliances; 

(6) Encryption and decryption means; 

(7) Secure communications means employing 
authentication, digital signaturing, and encrypted trans- 
missions. The secure subsystems at said user nodes 
utilize a protocol that establishes and authenticates each 
node's and/or participant's identity, and establishes one 
or more secure host-to-host encryption keys for com- 
munications between the secure subsystems; and 

(8) Secure control means that can allow each VDE 
installation to perform VDE content authoring (placing 
content into VDE containers with associated control 
information), content distribution, and content usage; 
as well as clearinghouse and other administrative and 
analysis activities employing content usage informa- 
tion. 

VDE may be used to migrate most non-electronic, tradi- 
tional information delivery models (including 
entertainment, reference materials, catalog shopping, etc.) 
into an adequately secure digital distribution and usage 
management and payment context. The distribution and 
financial pathways managed by a VDE arrangement may 
include: 

content creators), 

distributors), 

redistributor(s), 

client administrators), 

client user(s), 

financial and/or other clearinghouse^), 
and/or government agencies. 
These distribution and financial pathways may also include: 
advertisers, 

market survey organizations, and/or 

other parties interested in the user usage of information 
securely delivered and/or stored using VDE. 
Normally, participants in a VDE arrangement will employ 
the same secure VDE foundation. Alternate embodiments 
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support VDE arrangements employing differing VDE foun- Content providers who employ the present invention may 
dations. Such alternate embodiments may employ proce- include, for example, software application and game 
dures to ensure certain interoperability requirements are publishers, database publishers, cable, television, and radio 
met ' broadcasters, electronic shopping vendors, and distributors 
Secure VDE hardware (also known as SPUs for Secure s 0 f information in electronic document, book, periodical, 
Processing Units), or VDE installations that use software to c . mail and/or othcr forms Corporations, government 
substitute for, or complement, said hardware (provided by agencies, and/or individual "end-users" who act as storers 
Host Processing Environments (HPEs)), operate in conjunc- of and/or distributors of , electronic information, may also 
turn with secure communications, systems integration be VD£ content ^ (in a restficted model a user 
software, and distributed software control information and . « , , , . v , , J 
support structures, to achieve the electronic contract/rights 10 P r0Vldes ron * Qt °^ to ? imsc ? and emp oys VDE to secure 
protection environment of the present invention. Together, J B ™ a ^dental information against unauthorized use 
these VDE components comprise a secure, virtual, distrib- ^ other P arties >' El eclromc information may include pro- 
uted content and/or appliance control, auditing (and other pnetary and/or confidential information for personal or 
administration), reporting, and payment environment. In internal organization use, as well as information, such as 
some embodiments and where commercially acceptable, 35 software applications, documents, entertainment materials, 
certain VDE participants, such as clearinghouses that nor- and/or reference information, which may be provided to 
mally maintain sufficiently physically secure non-VDE pro- other parties. Distribution may be by, for example, physical 
cessing environments, may be allowed to employ HPEs media delivery, broadcast and/or telecommunication means, 
rather VDE hardware elements and interoperate, for and in the form of "static" files and/or streams of data. VDE 
example, with VDE end-users and content providers. VDE 20 may also be used, for example, for multi-site "real-time" 
components together comprise a configurable, consistent, interaction such as teleconferencing, interactive games, or 
secure and "trusted" architecture for distributed, asynchro- on-line bulletin boards, where restrictions on, and/or audit- 
nous control of electronic content and/or appliance usage. mg 0 f, the use of all or portions of communicated informa- 
VDE supports a "universe wide" environment for electronic tion is enforced. 

content delivery, broad dissemination, usage reporting, and 25 VDE provides important mechanisms for both enforcing 
usage related payment activities commercial agreements and enabling the protection of pri- 
VDE provides generalized configurabihty. 1ms results in ^ ^ ^ deliver mformation from one 
part, from decomposition of generahzed requirements for tQ &nother concernin me use of ^^^y dis . 
supporting electronic commerce and data secunty into a ; , J , , , , . . , % ; 
broad range of constituent "atomic" and higher level com- nibuted electromc content. Even if parties are separated by 
ponents (such as load modules, data elements, and methods) 30 several ste P s . f a chain tP^way) of handling for such 
that may be variously aggregated together to form control contenl information, such mformation is protected by 
methods for electronic commerce applications, commercial VDE trough encryption and/or other secure processing, 
electronic agreements, and data security arrangements. VDE Because of that protection, the accuracy of such information 
provides a secure operating environment employing VDE & guaranteed by VDE, and the information can be trusted by 
foundation elements along with secure independently deliv- 35 all parties to whom it is delivered. Furthermore, VDE 
erable VDE components that enable electronic commerce guarantees that all parties can trust that such information 
models and relationships to develop. VDE specifically sup- cannot be received by anyone other than the intended, 
ports the unfolding of distribution models in which content authorized, party(ies) because it is encrypted such that only 
providers, over time, can expressly agree to, or allow, an authorized party, or her agents, can decrypt it. Such 
subsequent content providers and/or users to participate in 40 information may also be derived through a secure VDE 
shaping the control information for, and consequences of, process at a previous pathway-of-handling location to pro- 
use of electronic content and/or appliances. A very broad duce secure VDE reporting information that is then corn- 
range of the functional attributes important for supporting municated securely to its intended recipient's VDE secure 
simple to very complex electronic commerce and data subsystem. Because VDE can deliver such information 
security activities are supported by capabilities of the 45 securely, parties to an electronic agreement need not trust the 
present invention. As a result, VDE supports most types of accuracy of commercial usage and/or other information 
electronic information and/or appliance: usage control delivered through means other than those under control of 
(including distribution), security, usage auditing* reporting, VDE. 

other administration, and payment arrangements. VDE participants in a commercial value chain can be 

VDE, in its preferred embodiment, employs object soft- 50 "commercially" confident (that is, sufficiently confident for 

ware technology and uses object technology to form "con- commercial purposes) that the direct (constituent) and/or 

tainers" for delivery of information that is (at least in part) "extended" electronic agreements they entered into through 

encrypted or otherwise secured. These containers may con- the use of VDE can be enforced reliably. These agreements 

tain electronic content products or other electronic informa- may have both "dynamic" transaction management related 

tion and some or all of their associated permissions (control) 55 aspects, such as content usage control information enforced 

information. These container objects may be distributed through budgeting, metering, and/or reporting of electronic 

along pathways involving content providers and/or content information and/or appliance use, and/or they may include 

users. They may be securely moved among nodes of a "static" electronic assertions, such as an end-user using the 

Virtual Distribution Environment (VDE) arrangement, system to assert his or her agreement to pay for services, not 

which nodes operate VDE foundation software and execute 60 to pass to unauthorized parties electronic information 

control methods to enact electronic information usage con- derived from usage of content or systems, and/or agreeing to 

trol and/or administration models. The containers delivered observe copyright laws. Not only can electronically reported 

through use of the preferred embodiment of the present transaction related information be trusted under the present 

invention may be employed both for distributing VDE invention, but payment may be automated by the passing of 

control instructions (information) and/or to encapsulate and 65 payment tokens through a pathway of payment (which may 

electronically distribute content that has been at least par- or may not be the same as a pathway for reporting). Such 

tially secured. payment can be contained within a VDE container created 
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automatically by a VDE installation in response to control 
information (located, in the preferred embodiment, in one or 
more permissions records) stipulating the "withdrawal" of 
credit or electronic currency (such as tokens) from an 
electronic account (for example, an account securely main- 
tained by a user's VDE installation secure subsystem) based 
upon usage of VDE controlled electronic content and/or 
appliances (such as governments, financial credit providers, 
and users). 

VDE allows the needs of electronic commerce partici- 
pants to be served and it can bind such participants together 
in a universe wide, trusted commercial network that can be 
secure enough to support very large amounts of commerce. 
VDE's security and metering secure subsystem core will be 
present at all physical locations where VDE related content 
is (a) assigned usage related control information (rules and 
mediating data), and/or (b) used. This core can perform 
security and auditing functions (including metering) that 
operate within a "virtual black box," a collection of 
distributed, very secure VDE related hardware instances that 
are interconnected by secured information exchange (for 
example, telecommunication) processes and distributed 
database means. VDE further includes highly configurable 
transaction operating system technology, one or more asso- 
ciated libraries of load modules along with affiliated data, 
VDE related administration, data preparation, and analysis 
applications, as well as system software designed to enable 
VDE integration into host environments and applications. 
VDE's usage control information, for example, provide for 
property content and/or appliance related: usage 
authorization, usage auditing (which may include audit 
reduction), usage billing, usage payment, privacy filtering, 
reporting, and security related communication and encryp- 
tion techniques. 

VDE extensively employs methods in the form of soft- 
ware objects to augment configurability, portability, and 
security of the VDE environment. It also employs a software 
object architecture for VDE content containers that carries 
protected content and may also carry both freely available 
information (e.g, summary, table of contents) and secured 
content control information which ensures the performance 
of control information. Content control information governs 
content usage according to criteria set by holders of rights to 
an object's contents and/or according to parties who other- 
wise have rights associated with distributing such content 
(such as governments, financial credit providers, and users). 

In part, security is enhanced by object methods employed 
by the present invention because the encryption schemes 
used to protect an object can efficiently be further used to 
protect the associated content control information (software 
control information and relevant data) from modification. 
Said object techniques also enhance portability between 
various computer and/or other appliance environments 
because electronic information in the form of content can be 
inserted along with (for example, in the same object con- 
tainer as) content control information (for said content) to 
produce a "published" object. As a result, various portions of 
said control information may be specifically adapted for 
different environments, such as for diverse computer plat- 
forms and operating systems, and said various portions may 
all be carried by a VDE container. 

An objective of VDE is supporting a transaction/ 
distribution control standard. Development of such a stan- 
dard has many obstacles, given the security requirements 
and related hardware and communications issues, widely 
differing environments, information types, types of infor- 
mation usage, business and/or data security goals, varieties 
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of participants, and properties of delivered information. A 
significant feature of VDE accommodates the many, varying 
distribution and other transaction variables by, in part, 
decomposing electronic commerce and data security func- 

s tions into generalized capability modules executable within 
a secure hardware SPU and/or corresponding software sub- 
system and further allowing extensive flexibility in 
assembling, modifying, and/or replacing, such modules (e.g. 
load modules and/or methods) in applications run on a VDE 

10 installation foundation. This configurability and reconfig- 
urability allows electronic commerce and data security par- 
ticipants to reflect their priorities and requirements through 
a process of iteratively shaping an evolving extended elec- 
tronic agreement (electronic control model). This shaping 

15 can occur as content control information passes from one 
VDE participant to another and to the extent allowed by "in 
place" content control information. This process allows 
users of VDE to recast existing control information and/or 
add new control information as necessary (including the 

2Q elimination of no longer required elements). 

VDE supports trusted (sufficiently secure) electronic 
information distribution and usage control models for both 
commercial electronic content distribution and data security 
applications. It can be configured to meet the diverse 

^ requirements of a network of interrelated participants that 
may include content creators, content distributors, client 
administrators, end users, and/or clearinghouses and/or 
other content usage information users. These parties may 
constitute a network of participants involved in simple to 

30 complex electronic content dissemination, usage control, 
usage reporting, and/or usage payment. Disseminated con- 
tent may include both originally provided and VDE gener- 
ated information (such as content usage information) and 
content control information may persist through both chains 

3S (one or more pathways) of content and content control 
information handling, as well as the direct usage of content. 
The configurability provided by the present invention is 
particularly critical for supporting electronic commerce, that 
is enabling businesses to create relationships and evolve 

4Q strategies that offer competitive value. Electronic commerce 
tools that are not inherently configurable and interoperable 
will ultimately fail to produce products (and services) that 
meet both basic requirements and evolving needs of most 
commerce applications. 

45 VDE's fundamental configurability will allow a broad 
range of competitive electronic commerce business models 
to flourish. It allows business models to be shaped to 
maximize revenues sources, end-user product value, and 
operating efficiencies. VDE can be employed to support 

5Q multiple, differing models, take advantage of new revenue 
opportunities, and deliver product configurations most 
desired by users. Electronic commerce technologies that do 
not, as the present invention does: 
support a broad range of possible, complementary rev- 

55 enue activities, 

offer a flexible array of content usage features most 

desired by customers, and 
exploit opportunities for operating efficiencies, 
will result in products that are often intrinsically more costly 

60 and less appealing and therefore less competitive in the 
marketplace. 

Some of the key factors contributing to the configurability 
intrinsic to the present invention include: 
(a) integration into the fundamental control environment 
65 of a broad range of electronic appliances through 
portable API and programming language tools that 
efficiently support merging of control and auditing 
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capabilities in nearly any electronic appliance environ- 
ment while maintaining overall system security; 

(b) modular data structures; 

(c) generic content model; 

(d) general modularity and independence of foundation 
architectural components; 

(e) modular security structures; 

(f) variable length and multiple branching chains of 
control; and 10 

(g) independent, modular control structures in the form of 
executable load modules that can be maintained in one 
or more libraries, and assembled into control methods 
and models, and where such model control schemes 
can "evolve" as control information passes through the 15 
VDE installations of participants of a pathway of VDE 
content control information handling. 

Because of the breadth of issues resolved by the present 
invention, it can provide the emerging "electronic highway" 
with a single transaction/distribution control system that 20 
can, for a very broad range of commercial and data security 
models, ensure against unauthorized use of confidential 
and/or proprietary information and commercial electronic 
transactions. VDE's electronic transaction management 
mechanisms can enforce the electronic rights and agree- 25 
ments of all parties participating in widely varying business 
and data security models, and this can be efficiently achieved 
through a single VDE implementation within each VDE 
participant's electronic appliance. VDE supports widely 
varying business and/or data security models that can 30 
involve a broad range of participants at various "levels" of 
VDE content and/or content control information pathways 
of handling. Different content control and/or auditing mod- 
els and agreements may be available on the same VDE 
installation. These models and agreements may control 35 
content in relationship to, for example, VDE installations 
and/or users in general; certain specific users, installations, 
classes and/or other groupings of installations and/or users; 
as well as to electronic content generally on a given 
installation, to specific properties, property portions, classes 40 
and/or other groupings of content. 

Distribution using VDE may package both the electronic 
content and control information into the same VDE 
container, and/or may involve the delivery to an end-user 
site of different pieces of the same VDE managed property 45 
from plural separate remote locations and/or in plural sepa- 
rate VDE content containers and/or employing plural dif- 
ferent delivery means. Content control information may be 
partially or fully delivered separately from its associated 
content to a user VDE installation in one or more VDE 50 
administrative objects. Portions of said control information 
may be delivered from one or more sources. Control infor- 
mation may also be available for use by access from a user's 
VDE installation secure sub-system to one or more remote 
VDE secure sub-systems and/or VDE compatible, certified 55 
secure remote locations. VDE control processes such as 
metering, budgeting, decrypting and/or fingerprinting, may 
as relates to a certain user content usage activity, be per- 
formed in a user's local VDE installation secure subsystem, 
or said processes may be divided amongst plural secure 60 
subsystems which may be located in the same user VDE 
installations and/or in a network server and in the user 
installation. For example, a local VDE installation may 
perform decryption and save any, or all of, usage metering 
information related to content and/or electronic appliance 65 
usage at such user installation could be performed at the 
server employing secure (e.g., encrypted) communications 
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between said secure subsystems. Said server location may 
also be used for near real time, frequent, or more periodic 
secure receipt of content usage information from said user 
installation, with, for example, metered information being 
maintained only temporarily at a local user installation. 

Delivery means for VDE managed content may include 
electronic data storage means such as optical disks for 
delivering one portion of said information and broadcasting 
and/or telecommunicating means for other portions of said 
information. Electronic data storage means may include 
magnetic media, optical media, combined magneto-optical 
systems, flash RAM memory, bubble memory, and/or other 
memory storage means such as huge capacity optical storage 
systems employing holographic, frequency, and/or polarity 
data storage techniques. Data storage means may also 
employ layered disc techniques, such as the use of generally 
transparent and/or translucent materials that pass light 
through layers of data carrying discs which themselves are 
physically packaged together as one thicker disc. Data 
carrying locations on such discs may be, at least in part, 
opaque. 

VDE supports a general purpose foundation for secure 
transaction management, including usage control, auditing, 
reporting, and/or payment. This general purpose foundation 
is called "VDE Functions" ("VDEFs"). VDE also supports 
a collection of "atomic" application elements (e.g., load 
modules) that can be selectively aggregated together to form 
various VDEF capabilities called control methods and which 
serve as VDEF applications and operating system functions. 
When a host operating environment of an electronic appli- 
ance includes VDEF capabilities, it is called a "Rights 
Operating System" (ROS). VDEF load modules, associated 
data, and methods form a body of information that for the 
purposes of the present invention are called "control infor- 
mation." VDEF control information may be specifically 
associated with one or more pieces of electronic content 
and/or it may be employed as a general component of the 
operating system capabilities of a VDE installation. 

VDEF transaction control elements reflect and enact 
content specific and/or more generalized administrative (for 
example, general operating system) control information. 
VDEF capabilities which can generally take the form of 
applications (application models) that have more or less 
configurability which can be shaped by VDE participants, 
through the use, for example, of VDE templates, to employ 
specific capabilities, along, for example, with capability 
parameter data to reflect the elements of one or more express 
electronic agreements between VDE participants in regards 
to the use of electronic content such as commercially 
distributed products. These control capabilities manage the 
use of, and/or auditing of use of, electronic content, as well 
as reporting information based upon content use, and any 
payment for said use. VDEF capabilities may "evolve" to 
reflect the requirements of one or more successive parties 
who receive or otherwise contribute to a given set of control 
information. Frequently, for a VDE application for a given 
content model (such as distribution of entertainment on 
CD-ROM, content delivery from an Internet repository, or 
electronic catalog shopping and advertising, or some com- 
bination of the above) participants would be able to securely 
select from amongst available, alternative control methods 
and apply related parameter data, wherein such selection of 
control method and/or submission of data would constitute 
their "contribution" of control information. Alternatively, or 
in addition, certain control methods that have been expressly 
certified as securely interoperable and compatible with said 
application may be independendy submitted by a participant 
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as part of such a contribution. In the most general example, (depending, for example, on legal requirements, previous 

a generally certified load module (certified for a given VDE exposure to such terms and conditions, and requirements of 

arrangement and/or content class) may be used with many or in place control information). 

any VDE application that operates in nodes of said arrange- VDEF capabilities may be employed, and a VDE agree- 
ment. These parties, to the extent they are allowed, can 5 ment may be entered into, by a plurality of parties without 
independently and securely add, delete, and/or otherwise the VDEF capabilities being directly associated with the 
modify the specification of load modules and methods, as controlling of certain, specific electronic information. For 
well as add, delete or otherwise modify related information. example, certain one or more VDEF capabilities may be 
Normally the party who creates a VDE content container present at a VDE installation, and certain VDE agreements 
defines the general nature of the VDEF capabilities that will 10 may have been entered into during the registration process 
and/or may apply to certain electronic information. A VDE for a content distribution application, to be used by such 
content container is an object that contains both content (for installation for securely controlling VDE content usage, 
example, commercially distributed electronic information auditing, reporting and/or payment. Similarly, a specific 
products such as computer software programs, movies, VDE participant may enter into a VDE user agreement with 
electronic publications or reference materials, etc.) and 15 a VDE content or electronic appliance provider when the 
certain control information related to the use of the object's user and/or her appliance register with such provider as a 
content. A creating party may make a VDE container avail- VDE installation and/or user. In such events, VDEF in place 
able to other parties. Control information delivered by, control information available to the user VDE installation 
and/or otherwise available for use with, VDE content con- may require that certain VDEF methods are employed, for 
tainers comprise (for commercial content distribution 20 example in a certain sequence, in order to be able to use all 
purposes) VDEF control capabilities (and any associated and/or certain classes, of electronic content and/or VDE 
parameter data) for electronic content. These capabilities applications. 

may constitute one or more "proposed" electronic agree- VDE ensures that certain prerequisites necessary for a 

ments (and/or agreement functions available for selection given transaction to occur are met. This includes the secure 

and/or use with parameter data) that manage the use and/or 25 execution of any required load modules and the availability 

the consequences of use of such content and which can enact of any required, associated data. For example, required load 

the terms and conditions of agreements involving multiple modules and data (e.g. in the form of a method) might 

parties and their various rights and obligations. specify that sufficient credit from an authorized source must 

A VDE electronic agreement may be explicit, through a be confirmed as available. It might further require certain 

user interface acceptance by one or more parties, for 30 one or more load modules execute as processes at an 

example by a "junior" party who has received control appropriate time to ensure that such credit will be used in 

information from a "senior" party, or it may be a process order to pay for user use of the content. A certain content 

amongst equal parties who individually assert their agree- provider might, for example, require metering the number of 

ment. Agreement may also result from an automated elec- copies made for distribution to employees of a given soft- 

tronic process during which terms and conditions are "evalu- 35 ware program (a portion of the program might be maintained 

ated" by certain VDE participant control information that in encrypted form and require the presence of a VDE 

assesses whether certain other electronic terms and condi- installation to run). This would require the execution of a 

tions attached to content and/or submitted by another party metering method for copying of the property each time a 

are acceptable (do not violate acceptable control information copy was made for another employee. This same provider 

criteria). Such an evaluation process may be quite simple, 40 might also charge fees based on the total number of different 

for example a comparison to ensure compatibility between properties licensed from them by the user and a metering 

a portion of, or all senior, control terms and conditions in a history of their licensing of properties might be required to 

table of terms and conditions and the submitted control maintain this information. 

information of a subsequent participant in a pathway of VDE provides organization, community, and/or universe 
content control information handling, or it may be a more 45 wide secure environments whose integrity is assured by 
elaborate process that evaluates the potential outcome of, processes securely controlled in VDE participant user instal- 
and/or implements a negotiation process between, two or lations (nodes). VDE installations, in the preferred 
more sets of control information submitted by two or more embodiment, may include both software and tamper resis- 
parties. VDE also accommodates a semi-automated process tant hardware semiconductor elements. Such a semiconduc- 
during which one or more VDE participants directly, 50 tor arrangement comprises, at least in part, special purpose 
through user interface means, resolve "disagreements" circuitry that has been designed to protect against tampering 
between control information sets by accepting and/or pro- with, or unauthorized observation of, the information and 
posing certain control information that may be acceptable to functions used in performing the VDE's control functions, 
control information representing one or more other parties The special purpose secure circuitry provided by the present 
interests and/or responds to certain user interface queries for 55 invention includes at least one of: a dedicated semiconductor 
selection of certain alternative choices and/or for certain arrangement known as a Secure Processing Unit (SPU) 
parameter information, the responses being adopted if and/or a standard microprocessor, microcontroller, and/or 
acceptable to applicable senior control information. other processing logic that accommodates the requirements 
When another party (other than the first applier of rules), of the present invention and functions as an SPU. VDE's 
perhaps through a negotiation process, accepts, and/or adds 60 secure hardware may be found incorporated into, for 
to and/or otherwise modifies, "in place" content control example, a fax/modem chip or chip pack, I/O controller, 
information, a VDE agreement between two or more parties video display controller, and/or other available digital pro- 
related to the use of such electronic content may be created cessing arrangements. It is anticipated that portions of the 
(so long as any modifications are consistent with senior present invention's VDE secure hardware capabilities may 
control information). Acceptance of terms and conditions 65 ultimately be standard design elements of central processing 
related to certain electronic content may be direct and units (CPUs) for computers and various other electronic 
express, or it may be implicit as a result of use of content devices. 
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Designing VDE capabilities into one or more standard 
microprocessor, microcontroller and/or other digital pro- 
cessing components may materially reduce VDE related 
hardware costs by employing the same hardware resources 
for both the transaction management uses contemplated by 5 
the present invention and for other, host electronic appliance 
functions. This means that a VDE SPU can employ (share) 
circuitry elements of a "standard" CPU. For example, if a 
"standard" processor can operate in protected mode and can 
execute VDE related instructions as a protected activity, then 
such an embodiment may provide sufficient hardware secu- 
rity for a variety of applications and the expense of a special 
purpose processor might be avoided. Under one preferred 
embodiment of the present invention, certain memory (e.g., 
RAM, ROM, NVRAM) is maintained during VDE related 15 
instruction processing in a protected mode (for example, as 
supported by protected mode microprocessors). This 
memory is located in the same package as the processing 
logic (e.g. processor). Desirably, the packaging and memory 
of such a processor would be designed using security 2 o 
techniques that enhance its resistance to tampering. 

The degree of overall security of the VDE system is 
primarily dependent on the degree of tamper resistance and 
concealment of VDE control process execution and related 
data storage activities. Employing special purpose semicon- 2 5 
ductor packaging techniques can significantly contribute to 
the degree of security. Concealment and tamper-resistance in 
semiconductor memory (e.g., RAM, ROM, NVRAM) can 
be achieved, in part, by employing such memory within an 
SPU package, by encrypting data before it is sent to external 30 
memory (such as an external RAM package) and decrypting 
encrypted data within the CPU/RAM package before it is 
executed. This process is used for important VDE related 
data when such data is stored on unprotected media, for 
example, standard host storage, such as random access 35 
memory, mass storage, etc. In that event, a VDE SPU would 
encrypt data that results from a secure VDE execution before 
such data was stored in external memory. 

Summary of Some Important Features Provided by VDE 
in Accordance With the Present Invention 40 

VDE employs a variety of capabilities that serve as a 
foundation for a general purpose, sufficiently secure distrib- 
uted electronic commerce solution. VDE enables an elec- 
tronic commerce marketplace that supports divergent, com- 
petitive business partnerships, agreements, and evolving 45 
overall business models. For example, VDE includes fea- 
tures that: 

"sufficiently" impede unauthorized and/or uncompen- 
sated use of electronic information and/or appliances 
through the use of secure communication, storage, and 50 
transaction management technologies. VDE supports a 
model wide, distributed security implementation which 
creates a single secure "virtual" transaction processing 
and information storage environment. VDE enables 
distributed VDE installations to securely store and 55 
communicate information and remotely control the 
execution processes and the character of use of elec- 
tronic information at other VDE installations and in a 
wide variety of ways; 

support low-cost, efficient, and effective security archi- 60 
tectures for transaction control, auditing, reporting, and 
related communications and information storage. VDE 
may employ tagging related security techniques, the 
time- ageing of encryption keys, the compartmentaliza- 
tion of both stored control information (including dif- 65 
ferentially tagging such stored information to ensure 
against substitution and tampering) and distributed 
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content (to, for many content applications, employ one 
or more content encryption keys that are unique to the 
specific VDE installation and/or user), private key 
techniques such as triple DES to encrypt content, 
public key techniques such as RSAto protect commu- 
nications and to provide the benefits of digital signature 
and authentication to securely bind together the nodes 
of a VDE arrangement, secure processing of important 
transaction management executable code, and a com- 
bining of a small amount of highly secure, hardware 
protected storage space with a much larger "exposed" 
mass media storage space storing secured (normally 
encrypted and tagged) control and audit information. 
VDE employs special purpose hardware distributed 
throughout some or all locations of a VDE implemen- 
tation: a) said hardware controlling important elements 
of: content preparation (such as causing such content to 
be placed in a VDE content container and associating 
content control information with said content), content 
and/or electronic appliance usage auditing, content 
usage analysis, as well as content usage control; and b) 
said hardware having been designed to securely handle 
processing load module control activities, wherein said 
control processing activities may involve a sequence of 
required control factors; 
support dynamic user selection of information subsets of 
a VDE electronic information product (VDE controlled 
content). This contrasts with the constraints of having 
to use a few high level individual, pre-defined content 
provider information increments such as being required 
to select a whole information product or product sec- 
tion in order to acquire or otherwise use a portion of 
such product or section. VDE supports metering and 
usage control over a variety of increments (including 
"atomic" increments, and combinations of different 
increment types) that are selected ad hoc by a user and 
represent a collection of pre -identified one or more 
increments (such as one or more blocks of a preiden- 
tified nature, e.g., bytes, images, logically related 
blocks) that form a generally arbitrary, but logical to a 
user, content "deliverable." VDE control information 
(including budgeting, pricing and metering) can be 
configured so that it can specifically apply, as 
appropriate, to ad hoc selection of different, unantici- 
pated variable user selected aggregations of informa- 
tion increments and pricing levels can be, at least in 
part, based on quantities and/or nature of mixed incre- 
ment selections (for example, a certain quantity of 
certain text could mean associated images might be 
discounted by 15%; a greater quantity of text in the 
"mixed" increment selection might mean the images 
are discounted 20%). Such user selected aggregated 
information increments can reflect the actual require- 
ments of a user for information and is more flexible 
than being limited to a single, or a few, high level, (e.g. 
product, document, database record) predetermined 
increments. Such high level increments may include 
quantities of information not desired by the user and as 
a result be more costly than the subset of information 
needed by the user if such a subset was available. In 
sum, the present invention allows information con- 
tained in electronic information products to be supplied 
according to user specification. Tailoring to user speci- 
fication allows the present invention to provide the 
greatest value to users, which in turn will generate the 
greatest amount of electronic commerce activity. The 
user, for example, would be able to define an aggrega- 
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lion of content derived from various portions of an 
available content product, but which, as a deliverable 
for use by the user, is an entirely unique aggregated 
increment. The user may, for example, select certain 
numbers of bytes of information from various portions 
of an information product, such as a reference work, 
and copy them to disc in unencrypted form and be 
billed based on total number of bytes plus a surcharge 
on the number of "articles" that provided the bytes. A 
content provider might reasonably charge less for such 
a user defined information increment since the user 
does not require all of the content from all of the 
articles that contained desired information. This pro- 
cess of defining a user desired information increment 
may involve artificial intelligence database search tools 
that contribute to the location of the most relevant 
portions of information from an information product 
and cause the automatic display to the user of infor- 
mation describing search criteria hits for user selection 
or the automatic extraction and delivery of such por- 
tions to the user. VDE further supports a wide variety 
of predefined increment types including: 
bytes, 
images, 

content over time for audio or video, or any other 
increment that can be identified by content provider 
data mapping efforts, such as: 

sentences, 

paragraphs, 

articles, 

database records, and 

byte offsets representing increments of logically related 
information. 

VDE supports as many simultaneous predefined increment 
types as may be practical for a given type of content and 
business model. 

securely store at a user's site potentially highly detailed 
information reflective of a user's usage of a variety of 
different content segment types and employing both 
inexpensive "exposed" host mass storage for maintain- 40 
ing detailed information in the form of encrypted data 
and maintaining summary information for security test- 
ing in highly secure special purpose VDE installation 
nonvolatile memory (if available), 
support trusted chain of handling capabilities for path- 45 
ways of distributed electronic information and/or for 
content usage related information. Such chains may 
extend, for example, from a content creator, to a 
distributor, a redistribute r, a client user, and then may 
provide a pathway for securely reporting the same 
and/or differing usage information to one or more 
auditors, such as to one or more independent clearing- 
houses and then back to the content providers, includ- 
ing content creators. The same and/or different path- 
ways employed for certain content handling, and 
related content control information and reporting infor- 
mation handling, may also be employed as one or more 
pathways for electronic payment handling (payment is 
characterized in the present invention as administrative 
content) for electronic content and/or appliance usage. 
These pathways are used for conveyance of all or 
portions of content, and/or content related control 
information. Content creators and other providers can 
specify the pathways that, partially or fully, must be 
used to disseminate commercially distributed property 
content, content control information, payment admin- 
istrative content, and/or associated usage reporting 
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information. Control information specified by content 
providers may also specify which specific parties must 
or may (including, for example, a group of eligible 
parties from which a selection may be made) handle 
conveyed information. It may also specify what trans- 
mission means (for example telecommunication carri- 
ers or media types) and transmission hubs must or may 
be used. 

support flexible auditing mechanisms, such as employing 
"bitmap meters," that achieve a high degree of effi- 
ciency of operation and throughput and allow, in a 
practical manner, the retention and ready recall of 
information related to previous usage activities and 
related patterns. This flexibility is adaptable to a wide 
variety of billing and security control strategies such as: 
upgrade pricing (e.g. suite purchases), 
pricing discounts (including quantity discounts), 
billing related time duration variables such as discount- 
ing new purchases based on the timing of past 
purchases, and 
security budgets based on quantity of different, logi- 
cally related units of electronic information used 
over an interval of time. 
Use of bitmap meters (including "regular" and "wide" 
bitmap meters) to record usage and/or purchase of 
information, in conjunction with other elements of the 
preferred embodiment of the present invention, 
uniquely supports efficient maintenance of usage his- 
tory for: (a) rental, (b) flat fee licensing or purchase, (c) 
licensing or purchase discounts based upon historical 
usage variables, and (d) reporting to users in a manner 
enabling users to determine whether a certain item was 
acquired, or acquired within a certain time period 
(without requiring the use of conventional database 
mechanisms, which are highly inefficient for these 
applications). Bitmap meter methods record activities 
associated with electronic appliances, properties, 
objects, or portions thereof, and/or administrative 
activities that are independent of specific properties, 
objects, etc., performed by a user and/or electronic 
appliance such that a content and/or appliance provider 
and/or controller of an administrative activity can 
determine whether a certain activity has occurred at 
some point, or during a certain period, in the past (for 
example, certain use of a commercial electronic content 
product and/or appliance). Such determinations can 
then be used as part of pricing and/or control strategies 
of a content and/or appliance provider, and/or control- 
ler of an administrative activity. For example, the 
content provider may choose to charge only once for 
access to a portion of a property, regardless of the 
number of times that portion of the property is accessed 
by a user. 

support "launchable" content, that is content that can be 
provided by a content provider to an end-user, who can 
then copy or pass along the content to other end-user 
parties without requiring the direct participation of a 
content provider to register and/or otherwise initialize 
the content for use. This content goes "out of (the 
traditional distribution) channel" in the form of a 
"traveling object." Traveling objects are containers that 
securely carry at least some permissions information 
and/or methods that are required for their use (such 
methods need not be carried by traveling objects if the 
required methods will be available at, or directly avail- 
able to a destination VDE installation). Certain travel- 
ling objects may be used at some or all VDE installa- 
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tions of a given VDE arrangement since they can make 
available the content control information necessary for 
content use without requiring the involvement of a 
commercial VDE value chain participant or data secu- 
rity administrator (e.g. a control officer or network 5 
administrator). As long as traveling object control 
information requirements are available at the user VDE 
installation secure subsystem (such as the presence of 
a sufficient quantity of financial credit from an autho- 
rized credit provider), at least some travelling object jo 
content may be used by a receiving party without the 
need to establish a connection with a remote VDE 
authority (until, for example, budgets are exhausted or 
a time content usage reporting interval has occurred). 
Traveling objects can travel "out-of-channel," ^ 
allowing, for example, a user to give a copy of a 
traveling object whose content is a software program, 
a movie or a game, to a neighbor, the neighbor being 
able to use the traveling object if appropriate credit 
(e.g. an electronic clearinghouse account from a clear- 2 o 
inghouse such as VISA or AT&T) is available. 
Similarly, electronic information that is generally avail- 
able on an Internet, or a similar network, repository 
might be provided in the form of a traveling object that 
can be downloaded and subsequently copied by the 25 
initial downloader and then passed along to other 
parties who may pass the object on to additional parties. 

provide very flexible and extensible user identification 
according to individuals, installations, by groups such 
as classes, and by function and hierarchical identifica- 30 
tion employing a hierarchy of levels of client identifi- 
cation (for example, client organization ID, client 
department ID, client network ID, client project ID, and 
client employee ID, or any appropriate subset of the 
above). 35 

provide a general purpose, secure, component based con- 
tent control and distribution system that functions as a 
foundation transaction operating system environment 
that employs executable code pieces crafted for trans- 
action control and auditing. These code pieces can be 40 
reused to optimize efficiency in creation and operation 
of trusted, distributed transaction management arrange- 
ments. VDE supports providing such executable code 
in the form of "atomic" load modules and associated 
data. Many such load modules are inherently 45 
configurable, aggregatable, portable, and extensible 
and singularly, or in combination (along with associ- 
ated data), run as control methods under the VDE 
transaction operating environment. VDE can satisfy the 
requirements of widely differing electronic commerce 50 
and data security applications by, in part, employing 
this general purpose transaction management founda- 
tion to securely process VDE transaction related con- 
trol methods. Control methods are created primarily 
through the use of one or more of said executable, 55 
reusable load module code pieces (normally in the form 
of executable object components) and associated data. 
The component nature of control methods allows the 
present invention to efficiently operate as a highly 
configurable content control system. Under the present 60 
invention, content control models can be iteratively and 
asynchronously shaped, and otherwise updated to 
accommodate the needs of VDE participants to the 
extent that such shaping and otherwise updating con- 
forms to constraints applied by a VDE application, if 65 
any (e.g., whether new component assemblies are 
accepted and, if so, what certification requirements 
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exist for such component assemblies or whether any or 
certain participants may shape any or certain control 
information by selection amongst optional control 
information (permissions record) control methods. This 
iterative (or concurrent) multiple participant process 
occurs as a result of the submission and use of secure, 
control information components (executable code such 
as load modules and/or methods, and/or associated 
data). These components may be contributed indepen- 
dently by secure communication between each control 
information influencing VDE participant's VDE instal- 
lation and may require certification for use with a given 
application, where such certification was provided by a 
certification service manager for the VDE arrangement 
who ensures secure interoperability and/or reliability 
(e.g., bug control resulting from interaction) between 
appliances and submitted control methods. The trans- 
action management control functions of a VDE elec- 
tronic appliance transaction operating environment 
interact with non-secure transaction management oper- 
ating system functions to properly direct transaction 
processes and data related to electronic information 
security, usage control, auditing, and usage reporting. 
VDE provides the capability to manages resources 
related to secure VDE content and/or appliance control 
information execution and data storage, 
facilitate creation of application and/or system function- 
ality under VDE and to facilitate integration into elec- 
tronic appliance environments of load modules and 
methods created under the present invention. To 
achieve this, VDE employs an Application Program- 
mer's Interface (API) and/or a transaction operating 
system (such as a ROS) programming language with 
incorporated functions, both of which support the use 
of capabilities and can be used to efficiently and tightly 
integrate VDE functionality into commercial and user 
applications. 

support user interaction through: (a) "Pop-Up" applica- 
tions which, for example, provide messages to users 
and enable users to take specific actions such as 
approving a transaction, (b) stand-alone VDE applica- 
tions that provide administrative environments for user 
activities such as: end-user preference specifications 
for limiting the price per transaction, unit of time, 
and/or session, for accessing history information con- 
cerning previous transactions, for reviewing financial 
information such as budgets, expenditures (e.g. detailed 
and/or summary) and usage analysis information, and 
(c) VDE aware applications which, as a result of the use 
of a VDE API and/or a transaction management (for 
example, ROS based) programming language embeds 
VDE "awareness" into commercial or internal software 
(application programs, games, etc.) so that VDE user 
control information and services are seamlessly inte- 
grated into such software and can be directly accessed 
by a user since the underlying functionality has been 
integrated into the commercial software's native 
design. For example, in a VDE aware word processor 
application, a user may be able to "print" a document 
into a VDE content container object, applying specific 
control information by selecting from amongst a series 
of different menu templates for different purposes (for 
example, a confidential memo template for internal 
organization purposes may restrict the ability to 
"keep," that is to make an electronic copy of the 
memo). 

employ "templates" to ease the process of configuring 
capabilities of the present invention as they relate to 
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specific industries or businesses. Templates are appli- 
cations or application add-ons under the present inven- 
tion. Templates support the efficient specification and/ 
or manipulation of criteria related to specific content 
types, distribution approaches, pricing mechanisms, 
user interactions with content and/or administrative 
activities, and/or the like. Given the very large range of 
capabilities and configurations supported by the present 
invention, reducing the range of configuration oppor- 
tunities to a manageable subset particularly appropriate 
for a given business model allows the full configurable 
power of the present invention to be easily employed 
by "typical" users who would be otherwise burdened 
with complex programming and/or configuration 
design responsibilities template applications can also 
help ensure that VDE related processes are secure and 
optimally bug free by reducing the risks associated with 
the contribution of independently developed load 
modules, including unpredictable aspects of code inter- 
action between independent modules and applications, 
as well as security risks associated with possible pres- 
ence of viruses in such modules. VDE, through the use 
of templates, reduces typical user configuration respon- 
sibilities to an appropriately focused set of activities 
including selection of method types (e.g. functionality) 
through menu choices such as multiple choice, icon 
selection, and/or prompting for method parameter data 
(such as identification information, prices, budget 
limits, dates, periods of time, access rights to specific 
content, etc.) that supply appropriate and/or necessary 
data for control information purposes. By limiting the 
typical (non-programming) user to a limited subset of 
configuration activities whose general configuration 
environment (template) has been preset to reflect gen- 
eral requirements corresponding to that user, or 
content or other business model can very substantially 
limit difficulties associated with content containeriza- 
tion (including placing initial control information on 
content), distribution, client administration, electronic 
agreement implementation, end-user interaction, and 
clearinghouse activities, including associated interop- 
erability problems (such as conflicts resulting from 
security, operating system, and/or certification 
incompatibilities). Use of appropriate VDE templates 
can assure users that their activities related to content 
VDE containerization, contribution of other control 
information, communications, encryption techniques 
and/or keys, etc. will be in compliance with specifica- 
tions for their distributed VDE arrangement. VDE 
templates constitute preset configurations that can nor- 
mally be reconfigurable to allow for new and/or modi- 
fied templates that reflect adaptation into new industries 
as they evolve or to reflect the evolution or other 
change of an existing industry. For example, the tem- 
plate concept may be used to provide individual, over- 
all frameworks for organizations and individuals that 
create, modify, market, distribute, consume, and/or 
otherwise use movies, audio recordings and live 
performances, magazines, telephony based retail sales, 
catalogs, computer software, information data bases, 
multimedia, commercial communications, 
advertisements, market surveys, infomercials, games, 
CAD/CAM services for numerically controlled 
machines, and the like. As the context surrounding 
these templates changes or evolves, template applica- 
tions provided under the present invention may be 
modified to meet these changes for broad use, or for 
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more focused activities. A given VDE participant may 
have a plurality of templates available for different 
tasks. A party that places content in its initial VDE 
container may have a variety of different, configurable 
templates depending on the type of content and/or 
business model related to the content. An end-user may 
have different configurable templates that can be 
applied to different document types (e-mail, secure 
internal documents, database records, etc.) and/or sub- 
sets of users (applying differing general sets of control 
information to different bodies of users, for example, 
selecting a list of users who may, under certain preset 
criteria, use a certain document). Of course, templates 
may, under certain circumstances have fixed control 
information and not provide for user selections or 
parameter data entry. 

support plural, different control models regulating the use 
and/or auditing of either the same specific copy of 
electronic information content and/or differently regu- 
lating different copies (occurrences) of the same elec- 
tronic information content. Differing models for 
billing, auditing, and security can be applied to the 
same piece of electronic information content and such 
differing sets of control information may employ, for 
control purposes, the same, or differing, granularities of 
electronic information control increments. This 
includes supporting variable control information for 
budgeting and auditing usage as applied to a variety of 
predefined increments of electronic information, 
including employing a variety of different budgets 
and/or metering increments for a given electronic infor- 
mation deliverable for: billing units of measure, credit 
limit, security budget limit and security content meter- 
ing increments, and/or market surveying and customer 
profiling content metering increments. For example, a 
CD-ROM disk with a database of scientific articles 
might be in part billed according to a formula based on 
the number of bytes decrypted, number of articles 
containing said bytes decrypted, while a security bud- 
get might limit the use of said database to no more than 
5% of the database per month for users on the wide area 
network it is installed on. 

provide mechanisms to persistently maintain trusted con- 
tent usage and reporting control information through 
both a sufficiently secure chain of handling of content 
and content control information and through various 
forms of usage of such content wherein said persistence 
of control may survive such use. Persistence of control 
includes the ability to extract information from a VDE 
container object by creating a new container whose 
contents are at least in part secured and that contains 
both the extracted content and at least a portion of the 
control information which control information of the 
original container and/or are at least in part produced 
by control information of the original container for this 
purpose and/or VDE installation control information 
stipulates should persist and/or control usage of content 
in the newly formed container. Such control informa- 
tion can continue to manage usage of container content 
if the container is "embedded" into another VDE man- 
aged object, such as an object which contains plural 
embedded VDE containers, each of which contains 
content derived (extracted) from a different source. 

enables users, other value chain participants (such as 
clearinghouses and government agencies), and/or user 
organizations, to specify preferences or requirements 
related to their use of electronic content and/or appli- 
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ances. Content users, such as end-user customers using 
commercially distributed content (games, information 
resources, software programs, etc.), can define, if 
allowed by senior control information, budgets, and/or 
other control information, to manage their own internal 5 
use of content. Uses include, for example, a user setting 
a limit on the price for electronic documents that the 
user is willing to pay without prior express user 
authorization, and the user establishing the character of 
metering information he or she is willing to allow to be 10 
collected (privacy protection). This includes providing 
the means for content users to protect the privacy of 
information derived from their use of a VDE installa- 
tion and content and/or appliance usage auditing. In 
particular, VDE can prevent information related to a 15 
participant's usage of electronic content from being 
provided to other parties without the participant's tacit 
or explicit agreement, 
provide mechanisms that allow control information to 
"evolve" and be modified according, at least in part, to 20 
independently, securely delivered further control infor- 
mation. Said control information may include execut- 
able code (e.g., load modules) that has been certified as 
acceptable (e.g., reliable and trusted) for use with a 
specific VDE application, class of applications, and/or 25 
a VDE distributed arrangement. This modification 
(evolution) of control information can occur upon 
content control information (load modules and any 
associated data) circulating to one or more VDE par- 
ticipants in a pathway of handling of control 30 
information, or it may occur upon control information 
being received from a VDE participant. Handlers in a 
pathway of handling of content control information, to 
the extent each is authorized, can establish, modify, 
and/or contribute to, permission, auditing, payment, 35 
and reporting control information related to controlling, 
analyzing, paying for, and/or reporting usage of, elec- 
tronic content and/or appliances (for example, as 
related to usage of VDE controlled property content). 
Independently delivered (from an independent source 40 
which is independent except in regards to certification), 
at least in part secure, control information can be 
employed to securely modify content control informa- 
tion when content control information has flowed from 
one party to another party in a sequence of VDE 45 
content control information handling. This modifica- 
tion employs, for example, one or more VDE compo- 
nent assemblies being securely processed in a VDE 
secure subsystem. In an alternate embodiment, control 
information may be modified by a senior party through 50 
use of their VDE installation secure sub-system after 
receiving submitted, at least in part secured, control 
information from a "junior" party, normally in the form 
of a VDE administrative object. Control information 
passing along VDE pathways can represent a mixed 55 
control set, in that it may include: control information 
that persisted through a sequence of control informa- 
tion handlers, other control information that was 
allowed to be modified, and further control information 
representing new control information and/or mediating 60 
data. Such a control set represents an evolution of 
control information for disseminated content. In this 
example the overall content control set for a VDE 
content container is "evolving" as it securely (e.g. 
communicated in encrypted form and using authenti- 65 
cation and digital signaturing techniques) passes, at 
least in part, to a new participant's VDE installation 
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where the proposed control information is securely 
received and handled. The received control information 
may be integrated (through use of the receiving parties' 
VDE installation secure sub -system) with in-place con- 
trol information through a negotiation process involv- 
ing both control information sets. For example, the 
modification, within the secure sub-system of a content 
provider's VDE installation, of content control infor- 
mation for a certain VDE content container may have 
occurred as a result of the incorporation of required 
control information provided by a financial credit pro- 
vider. Said credit provider may have employed their 
VDE installation to prepare and securely communicate 
(directly or indirectly) said required control informa- 
tion to said content provider. Incorporating said 
required control information enables a content provider 
to allow the credit provider's credit to be employed by 
a content end-user to compensate for the end-user's use 
of VDE controlled content and/or appliances, so long as 
said end-user has a credit account with said financial 
credit provider and said credit account has sufficient 
credit available. Similarly, control information requir- 
ing the payment of taxes and/or the provision of 
revenue information resulting from electronic com- 
merce activities may be securely received by a content 
provider. This control information may be received, for 
example, from a government agency. Content providers 
might be required by law to incorporate such control 
information into the control information for commer- 
cially distributed content and/or services related to 
appliance usage. Proposed control information is used 
to an extent allowed by senior control information and 
as determined by any negotiation trade-offs that satisfy 
priorities stipulated by each set (the received set and the 
proposed set). VDE also accommodates different con- 
trol schemes specifically applying to different partici- 
pants (e.g., individual participants and/or participant 
classes (types)) in a network of VDE content handling 
participants. 

support multiple simultaneous control models for the 
same content property and/or property portion. This 
allows, for example, for concurrent business activities 
which are dependent on electronic commercial product 
content distribution, such as acquiring detailed market 
survey information and/or supporting advertising, both 
of which can increase revenue and result in lower 
content costs to users and greater value to content 
providers. Such control information and/or overall con- 
trol models may be applied, as determined or allowed 
by control information, in differing manners to different 
participants in a pathway of content, reporting, 
payment, and/or related control information handling. 
VDE supports applying different content control infor- 
mation to the same and/or different content and/or 
appliance usage related activities, and/or to different 
parties in a content and/or appliance usage model, such 
that different parties (or classes of VDE users, for 
example) are subject to differing control information 
managing their use of electronic information content. 
For example, differing control models based on the 
category of a user as a distributor of a VDE controlled 
content object or an end-user of such content may result 
in different budgets being applied. Alternatively, for 
example, a one distributor may have the right to dis- 
tribute a different array of properties than another 
distributor (from a common content collection 
provided, for example, on optical disc). An individual, 
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and/or a class or other grouping of end-users, may have 
different costs (for example, a student, senior citizen, 
and/or poor citizen user of content who may be pro- 
vided with the same or differing discounts) than a 
"typical" content user. 5 

support provider revenue information resulting from cus- 
tomer use of content and/or appliances, and/or provider 
and/or end-user payment of taxes, through the transfer 
of credit and/or electronic currency from said end-user 
and/or provider to a government agency, might occur 
"automatically" as a result of such received control 
information causing the generation of a VDE content 
container whose content includes customer content 
usage information reflecting secure, trusted revenue 
summary information and/or detailed user transaction 15 
listings (level of detail might depend, for example on 
type or size of transaction — information regarding a 
bank interest payment to a customer or a transfer of a 
large (e.g. over $10,000) might be, by law, automati- 
cally reported to the government). Such summary and/ 20 
or detailed information related to taxable events and/or 
currency, and/or creditor currency transfer, may be 
passed along a pathway of reporting and/or payment to 
the government in a VDE container. Such a container 
may also be used for other VDE related content usage 25 
reporting information. 

support the flowing of content control information 
through different "branches" of content control infor- 
mation handling so as to accommodate, under the 
present invention's preferred embodiment, diverse con- 30 
trolled distributions of VDE controlled content. This 
allows different parties to employ the same initial 
electronic content with differing (perhaps competitive) 
control strategies. In this instance, a party who first 
placed control information on content can make certain 35 
control assumptions and these assumptions would 
evolve into more specific and/or extensive control 
assumptions. These control assumptions can evolve 
during the branching sequence upon content model 
participants submitting control information changes, 40 
for example, for use in "negotiating" with "in place" 
content control information. This can result in new or 
modified content control information and/or it might 
involve the selection of certain one or more already 
"in-place" content usage control methods over in -place 45 
alternative methods, as well as the submission of rel- 
evant control information parameter data. This form of 
evolution of different control information sets applied 
to different copies of the same electronic property 
content and/or appliance results from VDE control 50 
information flowing "down" through different branches 
in an overall pathway of handling and control and being 
modified differently as it diverges down these different 
pathway branches. This ability of the present invention 
to support multiple pathway branches for the flow of 55 
both VDE content control information and VDE man- 
aged content enables an electronic commerce market- 
place which supports diverging, competitive business 
partnerships, agreements, and evolving overall busi- 
ness models which can employ the same content prop- 60 
erties combined, for example, in differing collections of 
content representing differing at least in part competi- 
tive products. 

enable a user to securely extract, through the use of the 
secure subsystem at the user's VDE installation, at least 65 
a portion of the content included within a VDE content 
container to produce a new, secure object (content 
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container), such that the extracted information is main- 
tained in a continually secure mariner through the 
extraction process. Formation of the new VDE con- 
tainer containing such extracted content shall result in 
control information consistent with, or specified by, the 
source VDE content container, and/or local VDE instal- 
lation secure subsystem as appropriate, content control 
information. Relevant control information, such as 
security and administrative information, derived, at 
least in part, from the parent (source) object's control 
information, will normally be automatically inserted 
into a new VDE content container object containing 
extracted VDE content. This process typically occurs 
under the control framework of a parent object and/or 
VDE installation control information executing at the 
user's VDE installation secure subsystem (with, for 
example, at least a portion of this inserted control 
information being stored securely in encrypted form in 
one or more permissions records). In an alternative 
embodiment, the derived content control information 
applied to extracted content may be in part or whole 
derived from, or employ, content control information 
stored remotely from the VDE installation that per- 
formed the secure extraction such as at a remote server 
location. As with the content control information for 
most VDE managed content, features of the present 
invention allows the content's control information to: 

(a) "evolve," for example, the extractor of content may 
add new control methods and/or modify control 
parameter data, such as VDE application compliant 
methods, to the extent allowed by the content's 
in-place control information. Such new control infor- 
mation might specify, for example, who may use at 
least a portion of the new object, and/or how said at 
least a portion of said extracted content may be used 
(e.g. when at least a portion may be used, or what 
portion or quantity of portions may be used); 

(b) allow a user to combine additional content with at 
least a portion of said extracted content, such as 
material authored by the extractor and/or content (for 
example, images, video, audio, and/or text) extracted 
from one or more other VDE container objects for 
placement directly into the new container; 

(c) allow a user to securely edit at least a portion of said 
content while maintaining said content in a secure 
form within said VDE content container; 

(d) append extracted content to a pre-existing VDE 
content container object and attach associated con- 
trol information — in these cases, user added infor- 
mation may be secured, e.g., encrypted, in part or as 
a whole, and may be subject to usage and/or auditing 
control information that differs from the those 
applied to previously in place object content; 

(e) preserve VDE control over one or more portions of 
extracted content after various forms of usage of said 
portions, for example, maintain content in securely 
stored form while allowing "temporary'* on screen 
display of content or allowing a software program to 
be maintained in secure form but transiently decrypt 
any encrypted executing portion of said program (all, 
or only a portion, of said program may be encrypted 
to secure the program). 

Generally, the extraction features of the present invention 
allow users to aggregate and/or disseminate and/or other- 
wise use protected electronic content information extracted 
from content container sources while maintaining secure 
VDE capabilities thus preserving the rights of providers in 
said content information after various content usage pro- 
cesses. 
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support the aggregation of portions of VDE controlled 
content, such portions being subject to differing VDE 
content container control information, wherein various 
of said portions may have been provided by 
independent, different content providers from one or $ 
more different locations remote to the user performing 
the aggregation. Such aggregation, in the preferred 
embodiment of the present invention, may involve 
preserving at least a portion of the control information 
(e.g., executable code such as load modules) for each of 
various of said portions by, for example, embedding 
some or all of such portions individually as VDE 
content container objects within an overall VDE con- 
tent container and/or embedding some or all of such 
portions directly into a VDE content container. In the 
latter case, content control information of said content 35 
container may apply differing control information sets 
to various of such portions based upon said portions 
original control information requirements before aggre- 
gation. Each of such embedded VDE content contain- 
ers may have its own control information in the form of 20 
one or more permissions records. Alternatively, a nego- 
tiation between control information associated with 
various aggregated portions of electronic content, may 
produce a control information set that would govern 
some or all of the aggregated content portions. The 2 $ 
VDE content control information produced by the 
negotiation may be uniform (such as having the same 
load modules and/or component assemblies, and/or it 
may apply differing such content control information to 
two or more portions that constitute an aggregation of 30 
VDE controlled content such as differing metering, 
budgeting, billing and/or payment models, For 
example, content usage payment may be automatically 
made, either through a clearinghouse, or directly, to 
different content providers for different potions. 35 

enable flexible metering of, or other collection of infor- 
mation related to, use of electronic content and/or 
electronic appliances. Afeature of the present invention 
enables such flexibility of metering control mecha- 
nisms to accommodate a simultaneous, broad array of: 40 
(a) different parameters related to electronic informa- 
tion content use; (b) different increment units (bytes, 
documents, properties, paragraphs, images, etc.) and/or 
other organizations of such electronic content; and/or 
(c) different categories of user and/or VDE installation 45 
types, such as client organizations, departments, 
projects, networks, and/or individual users, etc. This 
feature of the present invention can be employed for 
content security, usage analysis (for example, market 
surveying), and/or compensation based upon the use 50 
and/or exposure to VDE managed content. Such meter- 
ing is a flexible basis for ensuring payment for content 
royalties, licensing, purchasing, and/or advertising. A 
feature of the present invention provides for payment 
means supporting flexible electronic currency and 55 
credit mechanisms, including the ability to securely 
maintain audit trails reflecting information related to 
use of such currency or credit. VDE supports multiple 
differing hierarchies of client organization control 
information wherein an organization client administra- 60 
tor distributes control information specifying the usage 
rights of departments, users, and/or projects. Likewise, 
a department (division) network manager can function 
as a distributor (budgets, access rights, etc.) for depart- 
ment networks, projects, and/or users, etc. $5 

provide scalable, integratable, standardized control means 
for use on electronic appliances ranging from inexpen- 
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sive consumer (for example, television set-top 
appliances) and professional devices (and hand-held 
PDAs) to servers, mainframes, communication 
switches, etc. The scalable transaction management/ 
auditing technology of the present invention will result 
in more efficient and reliable interoperability amongst 
devices functioning in electronic commerce and/or data 
security environments. As standardized physical con- 
tainers have become essential to the shipping of physi- 
cal goods around the world, allowing these physical 
containers to universally "fit" unloading equipment, 
efficiently use truck and train space, and accommodate 
known arrays of objects (for example, boxes) in an 
efficient manner, so VDE electronic content containers 
may, as provided by the present invention, be able to 
efficiently move electronic information content (such 
as commercially published properties, electronic cur- 
rency and credit, and content audit information), and 
associated content control information, around the 
world. Interoperability is fundamental to efficient elec- 
tronic commerce. The design of the VDE foundation, 
VDE load modules, and VDE containers, are important 
features that enable the VDE node operating environ- 
ment to be compatible with a very broad range of 
electronic appliances. The ability, for example, for 
control methods based on load modules to execute in 
very "small" and inexpensive secure sub-system 
environments, such as environments with very little 
read/write memory, while also being able to execute in 
large memory sub-systems that may be used in more 
expensive electronic appliances, supports consistency 
across many machines. This consistent VDE operating 
environment, including its control structures and con- 
tainer architecture, enables the use of standardized 
VDE content containers across a broad range of device 
types and host operating environments. Since VDE 
capabilities can be seamlessly integrated as extensions, 
additions, and/or modifications to fundamental capa- 
bilities of electronic appliances and host operating 
systems, VDE containers, content control information, 
and the VDE foundation will be able to work with 
many device types and these device types will be able 
to consistently and efficiently interpret and enforce 
VDE control information. Through this integration 
users can also benefit from a transparent interaction 
with many of the capabilities of VDE. VDE integration 
with software operating on a host electronic appliance 
supports a variety of capabilities that would be unavail- 
able or less secure without such integration. Through 
integration with one or more device applications and/or 
device operating environments, many capabilities of 
the present invention can be presented as inherent 
capabilities of a given electronic appliance, operating 
system, or appliance application. For example, features 
of the present invention include: (a) VDE system 
software to in part extend and/or modify host operating 
systems such that they possesses VDE capabilities, 
such as enabling secure transaction processing and 
electronic information storage; (b) one or more appli- 
cation programs that in part represent tools associated 
with VDE operation; and/or (c) code to be integrated 
into application programs, wherein such code incorpo- 
rates references into VDE system. software to integrate 
VDE capabilities and makes such applications VDE 
aware (for example, word processors, database 
retrieval applications, spreadsheets, multimedia pre- 
sentation authoring tools, film editing software, music 
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editing software such as MIDI applications and the 
like, robotics control systems such as those associated 
with CAD/CAM environments and NCM software and 
the like, electronic mail systems, teleconferencing 
software, and other data authoring, creating, handling, 5 
and/or usage applications including combinations of 
the above). These one or more features (which may also 
be implemented in firmware or hardware) may be 
employed in conjunction with a VDE node secure 
hardware processing capability, such as a 10 
microcontrollers), microprocessors), other CPU(s) or 
other digital processing logic. 

employ audit reconciliation and usage pattern evaluation 
processes that assess, through certain, normally net- 
work based, transaction processing reconciliation and 15 
threshold checking activities, whether certain viola- 
tions of security of a VDE arrangement have occurred. 
These processes are performed remote to VDE con- 
trolled content end-user VDE locations by assessing, 
for example, purchases, and/or requests, for electronic 20 
properties by a given VDE installation. Applications 
for such reconciliation activities include assessing 
whether the quantity of remotely delivered VDE con- 
trolled content corresponds to the amount of financial 
credit and/or electronic currency employed for the use 25 
of such content. A trusted organization can acquire 
information from content providers concerning the cost 
for content provided to a given VDE installation and/or 
user and compare this cost for content with the credit 
and/or electronic currency disbursements for that 30 
installation and/or user. Inconsistencies in the amount 
of content delivered versus the amount of disbursement 
can prove, and/or indicate, depending on the 
circumstances, whether the local VDE installation has 
been, at least to some degree, compromised (for 35 
example, certain important system security functions, 
such as breaking encryption for at least some portion of 
the secure subsystem and/or VDE controlled content by 
uncovering one or more keys). Determining whether 
irregular patterns (e.g. unusually high demand) of con- 40 
tent usage, or requests for delivery of certain kinds of 
VDE controlled information during a certain time 
period by one or more VDE installations and/or users 
(including, for example, groups of related users whose 
aggregate pattern of usage is suspicious) may also be 45 
useful in determining whether security at such one or 
more installations, and/or by such one or more users, 
has been compromised, particularly when used in com- 
bination with an assessment of electronic credit and/or 
currency provided to one or more VDE users and/or 50 
installations, by some or all of their credit and/or 
currency suppliers, compared with the disbursements 
made by such users and/or installations. 

support security techniques that materially increase the 
time required to "break" a system's integrity. This 55 
includes using a collection of techniques that mini- 
mizes the damage resulting from comprising some 
aspect of the security features of the present inventions. 

provide a family of authoring, administrative, reporting, 
payment, and billing tool user applications that com- 60 
prise components of the present invention's trusted/ 
secure, universe wide, distributed transaction control 
and administration system. These components support 
VDE related: object creation (including placing control 
information on content), secure object distribution and 65 
management (including distribution control 
information, financial related, and other usage 



,900 

36 

analysis), client internal VDE activities administration 
and control, security management, user interfaces, pay- 
ment disbursement, and clearinghouse related func- 
tions. These components are designed to support highly 
secure, uniform, consistent, and standardized: elec- 
tronic commerce and/or data security pathway(s) of 
handling, reporting, and/or payment; content control 
and administration; and human factors (e.g. user 
interfaces). 

support the operation of a plurality of clearinghouses, 
including, for example, both financial and user clear- 
inghouse activities, such as those performed by a client 
administrator in a large organization to assist in the 
organization's use of a VDE arrangement, including 
usage information analysis, and control of VDE activi- 
ties by individuals and groups of employees such as 
specifying budgets and the character of usage rights 
available under VDE for certain groups of and/or 
individual, client personnel, subject to control informa- 
tion series to control information submitted by the 
client administrator. At a clearinghouse, one or more 
VDE installations may operate together with a trusted 
distributed database environment (which may include 
concurrent database processing means). A financial 
clearinghouse normally receives at its location securely 
delivered content usage information, and user requests 
(such as requests for further credit, electronic currency, 
and/or higher credit limit). Reporting of usage infor- 
mation and user requests can be used for supporting 
electronic currency, billing, payment and credit related 
activities, and/or for user profile analysis and/or 
broader market survey analysis and marketing 
(consolidated) list generation or other information 
derived, at least in part, from said usage information, 
this information can be provided to content providers or 
other parties, through secure, authenticated encrypted 
communication to the VDE installation secure sub- 
systems. Clearinghouse processing means would nor- 
mally be connected to specialized I/O means, which 
may include high speed telecommunication switching 
means that may be used for secure communications 
between a clearinghouse and other VDE pathway par- 
ticipants. 

securely support electronic currency and credit usage 
control, storage, and communication at, and between, 
VDE installations. VDE further supports automated 
passing of electronic currency and/or credit 
information, including payment tokens (such as in the 
form of electronic currency or credit) or other payment 
information, through a pathway of payment, which said 
pathway may or may not be the same as a pathway for 
content usage information reporting. Such payment 
may be placed into a VDE container created automati- 
cally by a VDE installation in response to control 
information stipulating the "withdrawal" of credit or 
electronic currency from an electronic credit or cur- 
rency account based upon an amount owed resulting 
from usage of VDE controlled electronic content and/or 
appliances. Payment credit or currency may then be 
automatically communicated in protected (at least in 
part encrypted) form through telecommunication of a 
VDE container to an appropriate party such as a 
clearinghouse, provider of original property content or 
appliance, or an agent for such provider (other than a 
clearinghouse). Payment information may be packaged 
in said VDE content container with, or without, related 
content usage information, such as metering informa- 
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tion. An aspect of the present invention further enables 
certain information regarding currency use to be speci- 
fied as unavailable to certain, some, or all VDE parties 
("conditionally" to fully anonymous currency) and/or 
further can regulate certain content information, such 5 
as currency and/or credit use related information (and/ 
or other electronic information usage data) to be avail- 
able only under certain strict circumstances, such as a 
court order (which may itself require authorization 
through the use of a court controlled VDE installation 10 
that may be required to securely access "conditionally" 
anonymous information). Currency and credit 
information, under the preferred embodiment of the 
present invention, is treated as administrative content; 
support fingerprinting (also known as watermarking) for 15 
embedding in content such that when content protected 
under the present invention is released in clear form 
from a VDE object (displayed, printed, communicated, 
extracted, and/or saved), information representing the 
identification of the user and/or VDE installation 20 
responsible for transforming the content into clear form 
is embedded into the released content. Fingerprinting is 
useful in providing an ability to identify who extracted 
information in clear form a VDE container, or who 
made a copy of a VDE object or a portion of its 25 
contents. Since the identity of the user and/or other 
identifying information may be embedded in an 
obscure or generally concealed manner, in VDE con- 
tainer content and/or control information, potential 
copyright violators may be deterred from unauthorized 30 
extraction or copying. Fingerprinting normally is 
embedded into unencrypted electronic content or con- 
trol information, though it can be embedded into 
encrypted content and later placed in unencrypted 
content in a secure VDE installation sub-system as the 35 
encrypted content carrying the fingerprinting informa- 
tion is decrypted. Electronic information, such as the 
content of a VDE container, may be fingerprinted as it 
leaves a network (such as Internet) location bound for 
a receiving party. Such repository information may be 40 
maintained in unencrypted form prior to communica- 
tion and be encrypted as it leaves the repository. 
Fingerprinting would preferably take place as the con- 
tent leaves the repository, but before the encryption 
step. Encrypted repository content can be decrypted, 45 
for example in a secure VDE sub-system, fingerprint 
information can be inserted, and then the content can be 
re-encrypted for transmission. Embedding identifica- 
tion information of the intended recipient user and/or 
VDE installation into content as it leaves, for example, 50 
an Internet repository, would provide important infor- 
mation that would identify or assist in identifying any 
party that managed to compromise the security of a 
VDE installation or the delivered content. If a party 
produces an authorized clear form copy of VDE con- 55 
trolled content, including making unauthorized copies 
of an authorized clear form copy, fingerprint informa- 
tion would point back to that individual and/or his or 
her VDE installation. Such hidden information will act 
as a strong disincentive that should dissuade a substan- 60 
tial portion of potential content "pirates" from stealing 
other parties electronic information. Fingerprint infor- 
mation identifying a receiving party and/or VDE instal- 
lation can be embedded into a VDE object before, or 
during, decryption, replication, or communication of 65 
VDE content objects to receivers. Fingerprinting elec- 
tronic content before it is encrypted for transfer to a 
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customer or other user provides information that can be 
very useful for identifying who received certain content 
which may have then been distributed or made avail- 
able in unencrypted form. This information would be 
useful in tracking who may have "broken" the security 
of a VDE installation and was illegally making certain 
electronic content available to others. Fingerprinting 
may provide additional, available information such as 
time and/or date of the release (for example extraction) 
of said content information. Locations for inserting 
fingerprints may be specified by VDE installation and/ 
or content container control information. This informa- 
tion may specify that certain areas and/or precise 
locations within properties should be used for 
fingerprinting, such as one or more certain fields of 
information or information types. Fingerprinting infor- 
mation may be incorporated into a property by modi- 
fying in a normally undetectable way color frequency 
and/or the brightness of certain image pixels, by 
slightly modifying certain audio signals as to 
frequency, by modifying font character formation, etc. 
Fingerprint information, itself, should be encrypted so 
as to make it particularly difficult for tampered finger- 
prints to be interpreted as valid. Variations in finger- 
print locations for different copies of the same property; 
"false" fingerprint information; and multiple copies of 
fingerprint information within a specific property or 
other content which copies employ different finger- 
printing techniques such as information distribution 
patterns, frequency and/or brightness manipulation, 
and encryption related techniques, are features of the 
present invention for increasing the difficulty of an 
unauthorized individual identifying fingerprint loca- 
tions and erasing and/or modifying fingerprint infor- 
mation. 

provide smart object agents that can carry requests, data, 
and/or methods, including budgets, authorizations, 
credit or currency, and content. For example, smart 
objects may travel to and/or from remote information 
resource locations and fulfill requests for electronic 
information content. Smart objects can, for example, be 
transmitted to a remote location to perform a specified 
database search on behalf of a user or otherwise "intel- 
ligently" search remote one or more repositories of 
information for user desired information. After identi- 
fying desired information at one or more remote 
locations, by for example, performing one or more 
database searches, a smart object may return via com- 
munication to the user in the form of a secure "return 
object" containing retrieved information. A user may be 
charged for the remote retrieving of information, the 
returning of information to the user's VDE installation, 
and/or the use of such information. In the latter case, a 
user may be charged only for the information in the 
return object that the user actually uses. Smart objects 
may have the means to request use of one or more 
services and/or resources. Services include locating 
other services and/or resources such as information 
resources, language or format translation, processing, 
credit (or additional credit) authorization, etc. 
Resources include reference databases, networks, high 
powered or specialized computing resources (the smart 
object may carry information to another computer to be 
efficiently processed and then return the information to 
the sending VDE installation), remote object 
repositories, etc. Smart objects can make efficient use 
of remote resources (e.g. centralized databases, super 
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computers, etc.) while providing a secure means for 
charging users based on information and/or resources 
actually used. 

support both "translations" of VDE electronic agreements 
elements into modern language printed agreement ele- 
ments (such as English language agreements) and 
translations of electronic rights protection/transaction 
management modern language agreement elements to 
electronic VDE agreement elements. This feature 
requires maintaining a library of textual language that 
corresponds to VDE load modules and/or methods 
and/or component assemblies. As VDE methods are 
proposed and/or employed for VDE agreements, a 
listing of textual terms and conditions can be produced 
by a VDE user application which, in a preferred 
embodiment, provides phrases, sentences and/or para- 
graphs that have been stored and correspond to said 
methods and/or assemblies. This feature preferably 
employs artificial intelligence capabilities to analyze 
and automatically determine, and/or assist one or more 
users to determine, the proper order and relationship 
between the library elements corresponding to the 
chosen methods and/or assemblies so as to compose 
some or all portions of a legal or descriptive document. 
One or more users, and/or preferably an attorney (if the 
document a legal, binding agreement), would review 
the generated document material upon completion and 
employ such additional textual information and/or edit- 
ing as necessary to describe non electronic transaction 
elements of the agreement and make any other 
improvements that may be necessary. These features 
further support employing modern language tools that 
allow one or more users to make selections from 
choices and provide answers to questions and to pro- 
duce a VDE electronic agreement from such a process. 
This process can be interactive and the VDE agreement 
formulation process may employ artificial intelligence 
expert system technology that learns from responses 
and, where appropriate and based at least in part on said 
responses, provides further choices and/or questions 
which "evolves" the desired VDE electronic agree- 
ment. 

support the use of multiple VDE secure subsystems in a 
single VDE installation. Various security and/or per- 
formance advantages may be realized by employing a 
distributed VDE design within a single VDE installa- 
tion. For example, designing a hardware based VDE 
secure subsystem into an electronic appliance VDE 
display device, and designing said subsystem's inte- 
gration with said display device so that it is as close as 
possible to the point of display, will increase the 
security for video materials by making it materially 
more difficult to "steal" decrypted video information as 
it moves from outside to inside the video system. 
Ideally, for example, a VDE secure hardware module 
would be in the same physical package as the actual 
display monitor, such as within the packaging of a 
video monitor or other display device, and such device 
would be designed, to the extent commercially 
practical, to be as tamper resistant as reasonable. As 
another example, embedding a VDE hardware module 
into an I/O peripheral may have certain advantages 
from the standpoint of overall system throughput. If 
multiple VDE instances are employed within the same 
VDE installation, these instances will ideally share 
resources to the extent practical, such as VDE instances 
storing certain control information and content and/or 
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appliance usage information on the same mass storage 
device and in the same VDE management database. 

requiring reporting and payment compliance by employ- 
ing exhaustion of budgets and time ageing of keys. For 
example, a VDE commercial arrangement and associ- 
ated content control information may involve a content 
provider's content and the use of clearinghouse credit 
for payment for end-user usage of said content. Control 
information regarding said arrangement may be deliv- 
ered to a user's (of said content) VDE installation 
and/or said financial clearinghouse's VDE installation. 
Said control information might require said clearing- 
house to prepare and telecommunicate to said content 
provider both content usage based information in a 
certain form, and content usage payment in the form of 
electronic credit (such credit might be "owned" by the 
provider after receipt and used in lieu of the availability 
or adequacy of electronic currency) and/or electronic 
currency. This delivery of information and payment 
may employ trusted VDE installation secure sub- 
systems to securely, and in some embodiments, 
automatically, provide in the manner specified by said 
control information, said usage information and pay- 
ment content. Features of the present invention help 
ensure that a requirement that a clearinghouse report 
such usage information and payment content will be 
observed. For example, if one participant to a VDE 
electronic agreement fails to observe such information 
reporting and/or paying obligation, another participant 
can stop the delinquent party from successfully partici- 
pating in VDE activities related to such agreement. For 
example, if required usage information and payment 
was not reported as specified by content control 
information, the "injured" party can fail to provide, 
through failing to securely communicate from his VDE 
installation secure subsystem, one or more pieces of 
secure information necessary for the continuance of 
one or more critical processes. For example, failure to 
report information and/or payment from a clearing- 
house to a content provider (as well as any security 
failures or other disturbing irregularities) can result in 
the content provider not providing key and/or budget 
refresh information to the clearinghouse, which infor- 
mation can be necessary to authorize use of the clear- 
inghouse's credit for usage of the provider's content 
and which the clearinghouse would communicate to 
end-user's during a content usage reporting communi- 
cation between the clearinghouse and end -user. As 
another example, a distributor that failed to make 
payments and/or report usage information to a content 
provider might find that their budget for creating per- 
missions records to distribute the content provider's 
content to users, and/or a security budget limiting one 
or more other aspect of their use of the provider's 
content, are not being refreshed by the content provider, 
once exhausted or timed-out (for example, at a prede- 
termined date). In these and other cases, the offended 
party might decide not to refresh time ageing keys that 
had "aged out." Such a use of time aged keys has a 
similar impact as failing to refresh budgets or time- 
aged authorizations. 

support smart card implementations of the present inven- 
tion in the form of portable electronic appliances, 
including cards that can be employed as secure credit, 
banking, and/or money cards. A feature of the present 
invention is the use of portable VDEs as transaction 
cards at retail and other establishments, wherein such 
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cards can "dock" with an establishment terminal that 
has a VDE secure sub-system and/or an online con- 
nection to a VDE secure and/or otherwise secure and 
compatible subsystem, such as a "trusted" financial 
clearinghouse (e.g., VISA, Mastercard), The VDE card 5 
and the terminal (and/or online connection) can 
securely exchange information related to a transaction, 
with credit and/or electronic currency being transferred 
to a merchant and/or clearinghouse and transaction 
information flowing back to the card. Such a card can 10 
be used for transaction activities of all sorts. A docking 
station, such as a PCMCIA connector on an electronic 
appliance, such as a personal computer, can receive a 
consumer's VDE card at home. Such a station/card 
combination can be used for on-line transactions in the 15 
same manner as a VDE installation that is permanently 
installed in such an electronic appliance. The card can 
be used as an "electronic wallet" and contain electronic 
currency as well as credit provided by a clearinghouse. 
The card can act as a convergence point for financial 20 
activities of a consumer regarding many, if not all, 
merchant, banking, and on-line financial transactions, 
including supporting home banking activities. A con- 
sumer can receive his paycheck and/or investment 
earnings and/or "authentic" VDE content container 25 
secured detailed information on such receipts, through 
on-line connections. A user can send digital currency to 
another party with a VDE arrangement, including giv- 
ing away such currency. A VDE card can retain details 
of transactions in a highly secure and database orga- 30 
nized fashion so that financially related information is 
both consolidated and very easily retrieved and/or 
analyzed. Because of the VDE security, including use 
of effective encryption, authentication, digital 
signaturing, and secure database structures, the records 35 
contained within a VDE card arrangement may be 
accepted as valid transaction records for government 
and/or corporate recordkeeping requirements. In some 
embodiments of the present invention a VDE card may 
employ docking station and/or electronic appliance 40 
storage means and/or share other VDE arrangement 
means local to said appliance and/or available across a 
network, to augment the information storage capacity 
of the VDE card, by for example, storing dated, and/or 
archived, backup information. Taxes relating to some 45 
or all of an individual's financial activities may be 
automatically computed based on "authentic" informa- 
tion securely stored and available to said VDE card. 
Said information may be stored in said card, in said 
docking station, in an associated electronic appliance, 50 
and/or other device operatively attached thereto, and/or 
remotely, such as at a remote server site. A card's data, 
e.g. transaction history, can be backed up to an indi- 
vidual's personal computer or other electronic appli- 
ance and such an appliance may have an integrated 55 
VDE installation of its own. A current transaction, 
recent transactions (for redundancy), or all or other 
selected card data may be backed up to a remote backup 
repository, such a VDE compatible repository at a 
financial clearinghouse, during each or periodic dock- 60 
ing for a financial transaction and/or information com- 
munication such as a user/merchant transaction. Back- 
ing up at least the current transaction during a 
connection with another party's VDE installation (for 
example a VDE installation that is also on a financial or 65 
general purpose electronic network), by posting trans- 
action information to a remote clearinghouse and/or 
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bank, can ensure that sufficient backup is conducted to 
enable complete reconstruction of VDE card internal 
information in the event of a card failure or loss. 

support certification processes that ensure authorized 
interoperability between various VDE installations so 
as to prevent VDE arrangements and/or installations 
that unacceptably deviate in specification protocols 
from other VDE arrangements and/or installations from 
interoperating in a manner that may introduce security 
(integrity and/or confidentiality of VDE secured 
information), process control, and/or software compat- 
ibility problems. Certification validates the identity of 
VDE installations and/or their components, as well as 
VDE users. Certification data can also serve as infor- 
mation that contributes to determining the decommis- 
sioning or other change related to VDE sites. 

support the separation of fundamental transaction control 
processes through the use of event (triggered) based 
method control mechanisms. These event methods trig- 
ger one or more other VDE methods (which are avail- 
able to a secure VDE sub-system) and are used to carry 
out VDE managed transaction related processing. 
These triggered methods include independently 
(separably) and securely processable component billing 
management methods, budgeting management 
methods, metering management methods, and related 
auditing management processes. As a result of this 
feature of the present invention, independent triggering 
of metering, auditing, billing, and budgeting methods, 
the present invention is able to efficiently, concurrently 
support multiple financial currencies (e.g. dollars, 
marks, yen) and content related budgets, and/or billing 
increments as well as very flexible content distribution 
models. 

support, complete, modular separation of the control 
structures related to (1) content event triggering, (2) 
auditing, (3) budgeting (including specifying no right 
of use or unlimited right of use), (4) billing, and (5) user 
identity (VDE installation, client name, department, 
network, and/or user, etc.). The independence of these 
VDE control structures provides a flexible system 
which allows plural relationships between two or more 
of these structures, for example, the ability to associate 
a financial budget with different event trigger structures 
(that are put in place to enable controlling content 
based on its logical portions). Without such separation 
between these basic VDE capabilities, it would be more 
difficult to efficiently maintain separate metering, 
budgeting, identification, and/or billing activities which 
involve the same, differing (including overlapping), or 
entirely different, portions of content for metering, 
billing, budgeting, and user identification, for example, 
paying fees associated with usage of content, perform- 
ing home banking, managing advertising services, etc. 
VDE modular separation of these basic capabilities 
supports the programming of plural, "arbitrary" rela- 
tionships between one or differing content portions 
(and/or portion units) and budgeting, auditing, and/or 
billing control information. For example, under VDE, a 
budget limit of $200 dollars or 300 German Marks a 
month may be enforced for decryption of a certain 
database and 2 U.S. Dollars or 3 German Marks may be 
charged for each record of said database decrypted 
(depending on user selected currency). Such usage can 
be metered while an additional audit for user profile 
purposes can be prepared recording the identity of each 
filed displayed. Additionally, further metering can be 
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conducted regarding the number of said database bytes 
that have been decrypted, and a related security budget 
may prevent the decrypting of more than 5% of the total 
bytes of said database per year. The user may also, 
under VDE (if allowed by senior control information), 5 
collect audit information reflecting usage of database 
fields by different individuals and client organization 
departments and ensure that differing rights of access 
and differing budgets limiting database usage can be 
applied to these client individuals and groups. Enabling 10 
content providers and users to practically employ such 
diverse sets of user identification, metering, budgeting, 
and billing control information results, in part, from the 
use of such independent control capabilities. As a 
result, VDE can support great configurability in ere- is 
ation of plural control models applied to the same 
electronic property and the same and/or plural control 
models applied to differing or entirely different content 
models (for example, home banking versus electronic 
shopping). 20 
Methods, Other Control Information, and VDE Objects 
VDE control information (e.g., methods) that collectively 
control use of VDE managed properties (database, 
document, individual commercial product), are either 
shipped with the content itself (for example, in a content 25 
container) and/or one or more portions of such control 
information is shipped to distributors and/or other users in 
separably deliverable "administrative objects." A subset of 
the methods for a property may in part be delivered with 
each property while one or more other subsets of methods 30 
can be delivered separately to a user or otherwise made 
available for use (such as being available remotely by 
telecommunication means). Required methods (methods 
listed as required for property and/or appliance use) must be 
available as specified if VDE controlled content (such as 35 
intellectual property distributed within a VDE content 
container) is to be used. Methods that control content may 
apply to a plurality of VDE container objects, such as a class 
or other grouping of such objects. Methods may also be 
required by certain users or classes of users and/or VDE 40 
installations and/or classes of installations for such parties to 
use one or more specific, or classes of, objects. 

A feature of VDE provided by the present invention is that 
certain one or more methods can be specified as required in 
order for a VDE installation anoVor user to be able to use 45 
certain and/or all content. For example, a distributor of a 
certain type of content might be allowed by "senior" par- 
ticipants (by content creators, for example) to require a 
method which prohibits end-users from electronically sav- 
ing decrypted content, a provider of credit for VDE trans- 50 
actions might require an audit method that records the time 
of an electronic purchase, and/or a user might require a 
method that summarizes usage information for reporting to 
a clearinghouse (e.g. billing information) in a way that does 
not convey confidential, personal information regarding 55 
detailed usage behavior. 

A further feature of VDE provided by the present inven- 
tion is that creators, distributors, and users of content can 
select from among a set of predefined methods (if available) 
to control container content usage and distribution functions 60 
and/or they may have the right to provide new customized 
methods to control at least certain usage functions (such 
"new" methods may be required to be certified for trusted - 
ness and interoperability to the VDE installation and/or for 
of a group of VDE applications). As a result, VDE provides 65 
a very high degree of configurability with respect to how the 
distribution and other usage of each property or object (or 
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one or more portions of objects or properties as desired 
and/or applicable) will be controlled. Each VDE participant 
in a VDE pathway of content control information may set 
methods for some or all of the content in a VDE container, 
so long as such control information does not conflict with 
senior control information already in place with respect to: 

(1) certain or all VDE managed content, 

(2) certain one or more VDE users and/or groupings of 
users, 

(3) certain one or more VDE nodes and/or groupings of 
nodes, and/or 

(4) certain one or more VDE applications and/or arrange- 
ments. 

For example, a content creator's VDE control information 
for certain content can take precedence over other submitted 
VDE participant control information and, for example, if 
allowed by senior control information, a content distribu- 
tor's control information may itself take precedence over a 
client administrator's control information, which may take 
precedence over an end-user's control information. Apath of 
distribution participant's ability to set such electronic con- 
tent control information can be limited to certain control 
information (for example, method mediating data such as 
pricing and/or sales dates) or it may be limited only to the 
extent that one or more of the participant's proposed control 
information conflicts with control information set by senior 
control information submitted previously by participants in 
a chain of handling of the property, or managed in said 
participant's VDE secure subsystem. 

VDE control information may, in part or in full, (a) 
represent control information directly put in place by VDE 
content control information pathway participants, and/or (b) 
comprise control information put in place by such a partici- 
pant on behalf of a party who does not directly handle 
electronic content (or electronic appliance) permissions 
records information (for example control information 
inserted by a participant on behalf of a financial clearing- 
house or government agency). Such control information 
methods (and/or load modules and/or mediating data and/or 
component assemblies) may also be put in place by either an 
electronic automated, or a semi -automated and human 
assisted, control information (control set) negotiating pro- 
cess that assesses whether the use of one or more pieces of 
submitted control information will be integrated into and/or 
replace existing control information (and/or chooses 
between alternative control information based upon interac- 
tion with in-place control information) and how such control 
information may be used. 

Control information may be provided by a party who does 
not directly participate in the handling of electronic content 
(and/or appliance) and/or control information for such con- 
tent (and/or appliance). Such control information may be 
provided in secure form using VDE installation secure 
sub-system managed communications (including, for 
example, authenticating the deliverer of at least in part 
encrypted control information) between such not directly 
participating one or more parties' VDE installation secure 
subsystems, and a pathway of VDE content control infor- 
mation participant's VDE installation secure subsystem. 
This control information may relate to, for example, the 
right to access credit supplied by a financial services 
provider, the enforcement of regulations or laws enacted by 
a government agency, or the requirements of a customer of 
VDE managed content usage information (reflecting usage 
of content by one or more parties other than such customer) 
relating to the creation, handling and/or manner of reporting 
of usage information received by such customer. Such 
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control information may, for example, enforce societal 
requirements such as laws related to electronic commerce. 

VDE content control information may apply differently to 
different pathway of content and/or control information 
handling participants. Furthermore, permissions records 5 
rights may be added, altered, and/or removed by a VDE 
participant if they are allowed to take such action. Rights of 
VDE participants may be defined in relation to specific 
parties and/or categories of parties and/or other groups of 
parties in a chain of handling of content and/or content 1Q 
control information (e.g., permissions records). Modifica- 
tions to control information that may be made by a given, 
eligible party or parties, may be limited in the number of 
modifications, and/or degree of modification, they may 
make. s 

At least one secure subsystem in electronic appliances of 
creators, distributors, auditors, clearinghouses, client 
administrators, and end-users (understanding that two or 
more of the above classifications may describe a single user) 
provides a "sufficiently" secure (for the intended 2Q 
applications) environment for: 

1. Decrypting properties and control information; 

2. Storing control and metering related information; 

3. Managing communications; 

4. Processing core control programs, along with associ- 25 
ated data, that constitute control information for elec- 
tronic content and/or appliance rights protection, 
including the enforcing of preferences and require- 
ments of VDE participants. 

Normally, most usage, audit, reporting, payment, and 30 
distribution control methods are themselves at least in part 
encrypted and are executed by the secure subsystem of a 
VDE installation. Thus, for example, billing and metering 
records can be securely generated and updated, and encryp- 
tion and decryption keys are securely utilized, within a 35 
secure subsystem. Since VDE also employs secure (e.g. 
encrypted and authenticated) communications when passing 
information between the participant location (nodes) secure 
subsystems of a VDE arrangement, important components 
of a VDE electronic agreement can be reliably enforced with 40 
sufficient security (sufiBciently trusted) for the intended 
commercial purposes. A VDE electronic agreement for a 
value chain can be composed, at least in part, of one or more 
sub agreements between one or more subsets of the value 
chain participants. These subagreements are comprised of 45 
one or more electronic contract "compliance" elements 
(methods including associated parameter data) that ensure 
the protection of the rights of VDE participants. 

The degree of trustedness of a VDE arrangement will be 
primarily based on whether hardware SPUs are employed at 50 
participant location secure subsystems and the effectiveness 
of the SPU hardware security architecture, software security 
techniques when an SPU is emulated in software, and the 
encryption algorithm(s) and keys that are employed for 
securing content, control information, communications, and 55 
access to VDE node (VDE installation) secure subsystems. 
Physical facility and user identity authentication security 
procedures may be used instead of hardware SPUs at certain 
nodes, such as at an established financial clearinghouse, 
where such procedures may provide sufficient security for 60 
trusted interoperability with a VDE arrangement employing 
hardware SPUs at user nodes. 

The updating of property management files at each loca- 
tion of a VDE arrangement, to accommodate new or modi- 
fied control information, is performed in the VDE secure 65 
subsystem and under the control of secure management file 
updating programs executed by the protected subsystem. 
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Since all secure communications are at least in part 
encrypted and the processing inside the secure subsystem is 
concealed from outside observation and interference, the 
present invention ensures that content control information 
can be enforced. As a result, the creator and/or distributor 
and/or client administrator and/or other contributor of secure 
control information for each property (for example, an 
end-user restricting the kind of audit information he or she 
will allow to be reported and/or a financial clearinghouse 
establishing certain criteria for use of its credit for payment 
for use of distributed content) can be confident that their 
contributed and accepted control information will be 
enforced (within the security limitations of a given VDE 
security implementation design). This control information 
can determine, for example: 

(1) How and/or to whom electronic content can be 
provided, for example, how an electronic property can 
be distributed; 

(2) How one or more objects and/or properties, or portions 
of an object or property, can be directly used, such as 
decrypted, displayed, printed, etc; 

(3) How payment for usage of such content and/or content 
portions may or must be handled; and 

(4) How audit information about usage information 
related to at least a portion of a property should be 
collected, reported, and/or used. 

Seniority of contributed control information, including 
resolution of conflicts between content control information 
submitted by multiple parties, is normally established by: 

(1) the sequence in which control information is put in 
place by various parties (in place control information 
normally takes precedence over subsequently submit- 
ted control information), 

(2) the specifics of VDE content and/or appliance control 
information. For example, in-place control information 
can stipulate which subsequent one or more piece of 
control from one or more parties or class of parties will 
take precedence over control information submitted by 
one or more yet different parties and/or classes of 
parties, and/or 

(3) negotiation between control information sets from 
plural parties, which negotiation establishes what con- 
trol information shall constitute the resulting control 
information set for a given piece of VDE managed 
content and/or VDE installation. 

Electronic Agreements and Rights Protection 
An important feature of VDE is that it can be used to 
assure the administration of, and adequacy of security and 
rights protection for, electronic agreements implemented 
through the use of the present invention. Such agreements 
may involve one or more of: 

(1) creators, publishers, and other distributors, of elec- 
tronic information, 

(2) financial service (e.g. credit) providers, 

(3) users of (other than financial service providers) infor- 
mation arising from content usage such as content 
specific demographic information and user specific 
descriptive information. Such users may include mar- 
ket analysts, marketing list compilers for direct and 
directed marketing, and government agencies, 

(4) end users of content, 

(5) infrastructure service and device providers such as 
telecommunication companies and hardware manufac- 
turers (semiconductor and electronic appliance and/or 
other computer system manufacturers) who receive 
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compensation based upon the use of their services 
and/or devices, and 
(6) certain parties described by electronic information. 
VDE supports commercially secure "extended" value 
chain electronic agreements. VDE can be configured to 5 
support the various underlying agreements between parties 
that comprise this extended agreement. These agreements 
can define important electronic commerce considerations 
including: 

(1) security, 10 

(2) content use control, including electronic distribution, 

(3) privacy (regarding, for example, information concern- 
ing parties described by medical, credit, tax, personal, 
and/or of other forms of confidential information), 15 

(4) management of financial processes, and 

(5) pathways of handling for electronic content, content 
and/or appliance control information, electronic con- 
tent and/or appliance usage information and payment 
and/or credit. 20 

VDE agreements may define the electronic commerce 
relationship of two or more parties of a value chain, but such 
agreements may, at times, not directly obligate or otherwise 
directly involve other VDE value chain participants. For 
example, an electronic agreement between a content creator 25 
and a distributor may establish both the price to the dis- 
tributor for a creator's content (such as for a property 
distributed in a VDE container object) and the number of 
copies of this object that this distributor may distribute to 
end-users over a given period of time. In a second 30 
agreement, a value chain end-user may be involved in a 
three party agreement in which the end-user agrees to certain 
requirements for using the distributed product such as 
accepting distributor charges for content use and agreeing to 
observe the copyright rights of the creator. A third agreement 35 
might exist between the distributor and a financial clearing- 
house that allows the distributor to employ the clearing- 
house's credit for payment for the product if the end-user has 
a separate (fourth) agreement directly with the clearinghouse 
extending credit to the end-user. A fifth, evolving agreement 40 
may develop between all value chain participants as content 
control information passes along its chain of handling. This 
evolving agreement can establish the rights of all parties to 
content usage information, including, for example, the 
nature of information to be received by each party and the 45 
pathway of handling of content usage information and 
related procedures. A sixth agreement in this example, may 
involve all parties to the agreement and establishes certain 
general assumptions, such as security techniques and degree 
of trustedness (for example, commercial integrity of the 50 
system may require each VDE installation secure subsystem 
to electronically warrant that their VDE node meets certain 
interoperability requirements). In the above example, these 
six agreements could comprise agreements of an extended 
agreement for this commercial value chain instance. 55 

VDE agreements support evolving ("living") electronic 
agreement arrangements that can be modified by current 
and/or new participants through very simple to sophisticated 
"negotiations" between newly proposed content control 
information interacting with control information already in 60 
place and/or by negotiation between concurrently proposed 
content control information submitted by a plurality of 
parties. A given model may be asynchronously and progres- 
sively modified over time in accordance with existing senior 
rules and such modification may be applied to all, to classes 65 
of, and/or to specific content, and/or to classes and/or 
specific users and/or user nodes. A given piece of content 
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may be subject to different control information at different 
times or places of handling, depending on the evolution of 
its content control information (and/or on differing, appli- 
cable VDE installation content control information). The 
evolution of control information can occur during the pass- 
ing along of one or more VDE control information contain- 
ing objects, that is control information may be modified at 
one or more points along a chain of control information 
handling, so long as such modification is allowed. As a 
result, VDE managed content may have different control 
information applied at both different "locations" in a chain 
of content handling and at similar locations in differing 
chains of the handling of such content. Such different 
application of control information may also result from 
content control information specifying that a certain party or 
group of parties shall be subject to content control informa- 
tion that differs from another party or group of parties. For 
example, content control information for a given piece of 
content may be stipulated as senior information and there- 
fore not changeable, might be put in place by a content 
creator and might stipulate that national distributors of a 
given piece of their content may be permitted to make 
100,000 copies per calendar quarter, so long as such copies 
are provided to boni fide end-users, but may pass only a 
single copy of such content to a local retailers and the 
control information limits such a retailer to making no more 
than 1,000 copies per month for retail sales to end-users. In 
addition, for example, an end-user of such content might be 
limited by the same content control information to making 
three copies of such content, one for each of three different 
computers he or she uses (one desktop computer at work, 
one for a desktop computer at home, and one for a portable 
computer). 

Electronic agreements supported by the preferred 
embodiment of the present invention can vary from very 
simple to very elaborate. They can support widely diverse 
information management models that provide for electronic 
information security, usage administration, and communi- 
cation and may support: 

(a) secure electronic distribution of information, for 
example commercial literary properties, 

(b) secure electronic information usage monitoring and 
reporting, 

(c) secure financial transaction capabilities related to both 
electronic information and/or appliance usage and 
other electronic credit and/or currency usage and 
administration capabilities, 

(d) privacy protection for usage information a user does 
not wish to release, and 

(e) "living" electronic information content dissemination 
models that flexibly accommodate: 

(1) a breadth of participants, 

(2) one or more pathways (chains) for: the handling of 
content, content and/or appliance control 
information, reporting of content and/or appliance 
usage related information, and/or payment, 

(3) supporting an evolution of terms and conditions 
incorporated into content control information, 
including use of electronic negotiation capabilities, 

(4) support the combination of multiple pieces of 
content to form new content aggregations, and 

(5) multiple concurrent models. 
Secure Processing Units 

An important part of VDE provided by the present inven- 
tion is the core secure transaction control arrangement, 
herein called an SPU (or SPUs), that typically must be 
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present in each user's computer, other electronic appliance, FIG. 1 illustrates an example of a "Virtual Distribution 

or network. SPUs provide a trusted environment for gener- Environment" provided in accordance with a preferred 

ating decryption keys, encrypting and decrypting example/embodiment of this invention; 

information, managing the secure communication of keys nQ ^ is a more detaUed ainstraticm of an example of 

and omer mformaUon between elecfromc appliances (ix 5 mc "Information Utility" shown in FIG. 1; 

between VDE installations and/or between plural VDE 

instances within a single VDE installation), securely accu- FIG - 2 illustrates an example of a chain of handling and 

mulating and managing audit trail, reporting, and budget control; 

information in secure and/or non-secure non-volatile FIG. 2 A illustrates one example of how rules and control 

memory, maintaining a secure database of control informa- information may persist from one participant to another in 

tion management instructions, and providing a secure envi- the FIG. 2 chain of handling and control; 

ronment for performing certain other control and adminis- nG 3 shows Qne c fo of differeQl control informa _ 

trative functions. ^ on ^ m ^ G provided* 

Ahardware SFU (rather than a software emulation) within y P ' 

a VDE node is necessary if a highly trusted environment for FIG - 4 ^trates examples of some different types of 

performing certain VDE activities is required. Such a trusted 15 mIes and/or control information; 

environment may be created through the use of certain FIGS. 5A and 5B show an example of an "object"; 

control software, one or more tamper resistant hardware FIG. 6 shows an example of a Secure Processing Unit 

modules such as a semiconductor or semiconductor chipset ("SPU"); 

(including for example, a tamper resistant hardware elec FIG. 7 shows an example of an electronic appliance; 

tronic appliance peripheral device), for use within, and/or 30 _ . . . ., ...... r 

operatively connected to, an electronic appliance. With the u FIG * 8 15 a ^detailed block du^am of an example of 

present invention, the trustedness of a hardware SPU can be me appliance shown in FIG. 7; 

enhanced by enclosing some or all of its hardware elements FIG - 9 1S a detailed view of an example of the Secure 

within tamper resistant packaging and/or by employing Processing Unit (SPU) shown in FIGS. 6 and 8; 

other tamper resisting techniques (e.g. microfusing and/or 25 FIG. 9A shows an example combined secure processing 

thin wire detection techniques). A trusted environment of the unit and control processing unit; 

present invention implemented, in part, through the use of FIG. 9B shows an example secure processing unit inte- 

tamper resistant semiconductor design, contains control grated with a standard CPU; 

logic, such as a microprocessor, that securely executes VDE piG. 10 shows an example of a "Rights Operating Sys- 

processes. 30 tem „ (« R0S ^ arc hitecturc provided by the Virtual Distri- 

A VDE node's hardware SPU is a core component of a bution Environment* 

VDE secure subsystem and may employ some or all of an FIGS 11Ar . nc ^ow examples of functional relationship 

electronic appliance s primary control logic, such as a (s) betW6en applications ^ Ughts Operating System; 

microcontroller, microcomputer or other CPU arrangement. ... . . ... . „ . 

This primary control logic may be otherwise employed for ^ u FIGS * fow examplcs of ^P"™* and 

non VDE purposes such as the control of some or all of an component assemblies ; 

electronic appliance's non-VDE functions. When operating FIG * 12 15 a more detaUed digram of an example of the 

in a hardware SPU mode, said primary control logic must be Rl S hts Operating System shown in FIG. 10; 

sufficiently secure so as to protect and conceal important FIG. 12A shows an example of how "objects" can be 

VDE processes. For example, a hardware SPU may employ 40 created; 

a host electronic appliance microcomputer operating in FIG. 13 is a detailed block diagram of an example the 
protected mode while performing VDE related activities, software architecture for a "protected processing environ- 
thus allowing portions of VDE processes to execute with a menf shown in FIG. 12; 

certain degree of security. This alternate embodiment is in FIGS. 14A-14C are examples of SPU memory maps 

contrast to the preferred embodiment wherein a trusted 45 provided by the protected processing environment shown in 

environment is created using a combination of one or more FIG. 13; 

tamper resistant semiconductors that are not part of said FIG. 15 illustrates an example of how the channel services 

primary control logic. In either embodiment, certain control manager and load module execution manager of FIG. 13 can 

information (software and parameter data) must be securely support a channel* 

maintained within the SPU and further control information » pl(J ^ .. ^ ' ^ q[ ^ ^ 

can be stored externally and securely (e* m encrypted and ^ records sk)wn jn F]G lg 

tagged form) and loaded into said hardware SPU when , , 

needed. In many cases, and in particular with , HG ' 15 3 fl ° Wch ?f ° f "? «™Pl» o«W™ OTtr °i 

microcomputers, the preferred embodiment approach of ste * s * at ma >! be Permed by the FIG. 13 protected 

employing special purpose secure hardware for executing « P™***"* environment to create a channel; 

said VDE processes, rather than using said primary control FIG - 16 1S a blodc diagram of an example of a secure data 

logic, may be more secure and efficient. The level of security base structure; 

and tamper resistance required for trusted SPU hardware FIG. 17 is an illustration of an example of a logical object 

processes depends on the commercial requirements of par- structure; 

ticular markets or market niches, and may vary widely. 60 FIG. 18 shows an example of a stationary object structure; 

BRIEF DESCRIPTION OF THE DRAWINGS FIG - 19 shows an example of a traveling object structure; 

T^ese and other features and advantages provided by the nG ' 20 shows " exam P le of a 00111601 ob j ecl structure i 

present inventions) may be better and more completely FlG - 21 shows ™ example of an administrative object 

understood by referring to the following detailed description 65 stru c turc i 

of presently preferred example embodiments in connection FIG. 22 shows an example of a method core structure; 

with the drawings, of which: FIG. 23 shows an example of a load module structure; 
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FIG. 24 shows an example of a User Data Element (UDE) 
and/or Method Data Element (MDE) structure; 

FIGS. 25A-25C show examples of "map meters"; 

FIG. 26 shows an example of a permissions record 
(PERC) structure; 

FIGS. 26 A and 26B together show a more detailed 
example of a permissions record structure; 

FIG. 27 shows an example of a shipping table structure; 

FIG. 28 shows an example of a receiving table structure; 

FIG. 29 shows an example of an administrative event log 
structure; 

FIG. 30 shows an example inter-relationship between and 
use of the object registration table, subject table and user 
rights table shown in the FIG. 16 secure database; 

FIG. 31 is a more detailed example of an object registra- 
tion table shown in FIG. 16; 

FIG. 32 is a more detailed example of subject table shown 
in FIG. 16; 

FIG. 33 is a more detailed example of a user rights table 
shown in FIG. 16; 

FIG. 34 shows a specific example of how a site record 
table and group record table may track portions of the secure 
database shown in FIG. 16; 

FIG. 34A is an example of a FIG. 34 site record table 
structure; 

FIG. 34B is an example of a FIG. 34 group record table 
structure; 

FIG. 35 shows an example of a process for updating the 
secure database; 

FIG. 36 shows an example of how new elements may be 
inserted into the FIG. 16 secure data base; 

FIG. 37 shows an example of how an element of the 
secure database may be accessed; 

FIG. 38 is a flowchart example of how to protect a secure 
database element; 

FIG. 39 is a flowchart example of how to back up a secure 
database; 

FIG. 40 is a flowchart example of how to recover a secure 
database from a backup; 

FIGS. 41A-41D are a set of examples showing how a 
"chain of handling and control" may be enabled using 
"reciprocal methods"; 

FIGS. 42A-42D show an example of a "reciprocal** 
BUDGET method; 

FIGS. 43A-43D show an example of a "reciprocal" 
REGISTER method; 

FIGS. 44A-44C show an example of a "reciprocal" 
AUDIT method; 

FIGS. 45-48 show examples of several methods being 
used together to control release of content or other infor- 
mation; 

FIGS. 49, 49A-49F show an example OPEN method; 
FIGS. 50, 50A-50F show an example of a READ method; 
FIGS. 51, 51A-51F show an example of a WRITE 
method; 

FIG. 52 shows an example of a CLOSE method; 
FIGS. 53A-53B show an example of an EVENT method; 
FIG. 53C shows an example of a BILLING method; 
FIG. 54 shows an example of an ACCESS method; 
FIGS. 55A-55B show examples of DECRYPT and 
ENCRYPT methods; 
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FIG. 56 shows an example of a CONTENT method; 

FIGS. 57A and 57B show examples of EXTRACT and 
EMBED methods; 

FIG. 58A shows an example of an OBSCURE method; 
5 FIGS. 58B, 58C show examples of a FINGERPRINT 
method; 

FIG. 59 shows an example of a DESTROY method; 
FIG. 60 shows an example of a PANIC method; 
10 FIG. 61 shows an example of a METER method; 

FIG. 62 shows an example of a key "convolution" pro- 
cess; 

FIG. 63 shows an example of how different keys may be 
15 generated using a key convolution process to determine a 
"true" key; 

FIGS. 64 and 65 show an example of how protected 
processing environment keys may be initialized; 

FIGS. 66 and 67 show example processes for decrypting 
20 information contained within stationary and traveling 
objects, respectively; 

FIGS. 67A and 67B show example techniques for crack- 
ing a software-based protected processing environment; 

FIG. 68 shows an example of how a protected processing 
25 environment may be initialized; 

FIG. 69 shows an example of how firmware may be 
downloaded into a protected processing environment; 

FIG. 69A shows an example technique for distributing 
3Q protected processing environment software; 

FIGS. 69B-69C show an example installation routine for 
installing a software-based protected processing environ- 
ment; 

FIG. 69D shows example techniques for embedding cryp- 
35 tographic keys at random locations within structure-based 
protected processing environment operational materials; 

FIG. 69E shows example locations for PPE operational 
materials random modifications and/or digital fingerprints; 
FIG. 69F shows an example customized static storage 
40 layout for PPE operational materials; 

FIG. 69G shows example electronic appliance signature 
locations; 

FIG. 69H shows example sequence dependent and inde- 
45 pendent processes; 

FIGS. 691 and 69J show example static code and data 
storage organizations; 

FIGS. 6 9K-69L together show example steps for provid- 
ing dynamic protection mechanisms; 
50 FIG. 69M shows an example initialization time check 
routine; 

FIG. 69N shows an example time check routine; 

FIG. 690 shows example time check data structures; 

FIG. 70 shows an example of multiple VDE electronic 
55 appliances connected together with a network or other 
communications means; 

FIG. 70Ashows how content may be prepared for printing 
and encrypted inside a PPE, then decrypted inside a printer; 
60 FIG. 70B shows how characters may be selected from 
slightly different fonts in order to place an electronic fin- 
gerprint or watermark into printed output; 

FIG. 70C shows how characters in a font may be per- 
muted to render a printed page unusable without the corre- 
65 sponding scrambled font; 

FIG. 71 shows an example of a portable VDE electronic 
appliance; 
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FIGS. 72A-72D show examples of "pop-up" displays that information was distributed on records or disks that were 

may be generated by the user notification and exception difficult to copy. In the past, private or secret content was 

interface; distributed in sealed envelopes or locked briefcases deliv- 

FIG. 73 shows an example of a "smart object"; ered bv courier ' To e 1 nsure 1 appropriate compensation, con- 

, . « 5 sumers received goods and services only after they handed 

FIG.^74 shows an example of a process using smart cash over t0 a seller M]hough information utility 200 may 

objects ; deliver information by transferring physical "things" such as 

FIGS. 75A-75D show examples of data structures used electronic storage media, the virtual distribution environ* 

for electronic negotiation; ment 100 facilitates a completely electronic "chain of han- 

FIGS. 75E-75F show example structures relating to an 10 dling and control." 

electronic agreement; VDE Flexibility Supports Transactions 

FIGS. 76A-76B show examples of electronic negotiation Information utility 200 flexibly supports many different 

processes; kinds of information transactions Different VDE participants 

™« „ * - . c . . r u ji* mav define and/or participate in different parts of a trans- 

F1G. 77 shows a further example of a chain of handling J T c .. r ^ A i r - , , u j r 

, . , y i< action. Information utility 200 may assist with delivering 

and control; 15 . f . , , , . J .„ . c & 

mformation about a transaction, or it may be one of the 

FIG. 78 shows an example of a VDE "repository"; transaction participants. 

FIGS. 79—83 show an example illustrating a chain of For example, the video production studio 204 in the upper 

handling and control to evolve and transform VDE managed right-hand corner of FIG. 1 may create video/television 

content and control information; 2Q programs. Video production studio 204 may send these 

FIG. 84 shows a further example of a chain of handling programs over lines 202, or may use other paths such as 

and control involving several categories of VDE partici- satellite link 205 and CD ROM delivery service 216. Video 

pants; production studio 204 can send the programs directly to 

FIG. 85 shows a further example of a chain of distribution consumers 206, 208, 210, or it can send the programs to 

and handling within an organization; 25 information utility 200 which may store and later send them 

r-ir^o o£. j q£. a l i c x. ■ c to the consumers, for example. Consumers 206, 208, 210 are 

FIGS. 86 and 86Ashow a further example of a chain of , «, - ' . . * . . ' 

handlin and control* and e ca P aD * e °* receiving and using the programs created by 

B ' video production studio 204 — assuming, that is, that the 

FIG. 87 shows an example of a virtual silicon container video pro duction studio or information utility 200 has 

moQi el. 30 arranged for these consumers to have appropriate "rules and 

MORE DETAILED DESCRIPTION °°Tf ^.f 01 iatotm!itioD ) that »™ the consumers 

rights to use the programs. 

FIGS. 1-7 and the discussion below provides an overview Even if a consumer has a copy of a video program, she 

of some aspects of features provided by this invention. cannot watch or copy the program unless she has "rules and 

Following this overview is a more technical "detail descrip- 35 controls" that authorize use of the program. She can use the 

tion" of example embodiments in accordance with the program only as permitted by the "rules and controls." 

invention. For example, video production studio 204 might release a 

Overview half-hour exercise video in the hope that as many viewers as 

r, rri i u 1 * u *• n * ^» possible will view it. The video production studio 204 

FIG. 1 shows a Virtual Distribution Environment ... ™ • w .. j 

mn *u * u -a a • _i *u *u* an wishes to receive $2.00 per viewing. Video production 

("VDE ) 100 that may be provided in accordance with this 40 t . . r f - ftA r , t . 

• * * t i • * ** 4ftn * . studio 204 may, through information utility 200, make the 

invention. In FIG, 1. an information utility 200 connects to , . f ■ « . , j» c * 11 

. -ft* , . . : •« rwri j exercise video available in protected form to all consum- 

communications means 202 such as telephone or cable TV - n , - AO ^ A j * j- <%nA ^ 

v c t rwy 1 1 U1 xiia , ers 206, 208, 210. Video production studio 204 may also 

lines for example. Telephone or cable TV lines 202 may be \ ( ' , 4 . r ™ (( / , 

. c « i 4 • • i „ , . , . . . % provide "rules and controls for the video. These "rules and 

part of an electronic highway^ that carries electronic inf or- . ,« -r e i 

mation from place to place. Lines 202 connect information 45 consols may specify for example: 

utility 200 to other people such as for example a consumer (1) any consumer who has good credit of at least $2.00 

208, an office 210, a video production studio 204, and a based on a credit account with independent financial 

publishing house 214. Each of the people connected to provider 212 (such as Mastercard or VISA) may watch 

information utility 200 may be called a "VDE participant" me vldeo > 

because they can participate in transactions occurring within 50 (2) virtual distribution environment 100 will "meter" each 

the virtual distribution environment 100. time a consumer watches the video, and report usage to 

A1 ^ r . ... . - , video production studio 204 from time to time, and 

Almost any sort of transaction you can think of can be „ r . , . , ^ A , 

supported by virtual distribution environment 100. A few of ( 3 > finan = 1 * 1 P~ videf I 12 m V electromc ? 11 y f llect 

many examples of transactions that can be supported by m u ent ( $2 °°) b ° m « he ^ acc0 " nt ° f each consu , mer 

virtual distribution environment 100 include: 55 who watches Ae video, and transfer these payments to 

^ . . the video production studio 204. 
home banking and electrons payments; Information utility 200 allows even a small video pro- 
electronic legal contracts; duction studio to market videos to consumers and receive 

f distribution of "content" such as electronic printed matter, compensation for its efforts. Moreover, the videos can, with 

video, audio, images and computer programs; and 60 appropriate payment to the video production studio, be made 

secure communication of private information such as available to other video publishers who may add value 

medical records and financial information. and/or act as repackagers or redistributors. 

Virtual distribution environment 100 is "virtual" because FIG. 1 also shows a publishing house 214. Publishing 

it does not require many of the physical "things" that used house 214 may act as a distributor for an author 206. The 

to be necessary to protect rights, ensure reliable and pre- 65 publishing house 214 may distribute rights to use "content" 

dictable distribution, and ensure proper compensation to (such as computer software, electronic newspapers, the 

content creators and distributors. For example, in the past, video produced by publishing house 214, audio, or any other 
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data) to consumers such as office 210. The use rights may be 
defined by "rules and controls" distributed by publishing 
house 216. Publishing house 216 may distribute these "rules 
and controls" with the content, but this is not necessary. 
Because the content can be used only by consumers that 
have the appropriate "rules and controls," content and its 
associated "rules and controls" may be distributed at differ- 
ent times, in different ways, by different VDE participants. 
The ability of VDE to securely distribute and enforce "rules 
and controls" separately from the content they apply to 
provides great advantages. 

Use rights distributed by publishing house 214 may, for 
example, permit office 210 to make and distribute copies of 
the content to its employees. Office 210 may act as a 
redistributor by extending a "chain of handling and control" 
to its employees. The office 210 may add or modify "rules 
and controls" (consistent with the "rules and controls" it 
receives from publishing house 214) to provide office- 
internal control information and mechanisms. For example, 
office 210 may set a maximum usage budget for each 
individual user and/or group within the office, or it may 
permit only specified employees and/or groups to access 
certain information. 

FIG. 1 also shows an information delivery service 216 
delivering electronic storage media such as "CD ROM" 
disks to consumers 206. Even though the electronic storage 
media themselves are not delivered electronically by infor- 
mation utility 200 over lines 202, they are still part of the 
virtual distribution environment 100. The electronic storage 
media may be used to distribute content, "rules and 
controls/' or other information. 

Example of What's Inside Information Utility 200 

"Information utility" 200 in FIG. 1 can be a collection of 
participants that may act as distributors, financial 
clearinghouses, and administrators. FIG. 1A shows an 
example of what may be inside one example of information 
utility 200. Information utility participants 200a-200g could 
each be an independent organization/business. There can be 
any number of each of participants 200a-200g. In this 
example, electronic "switch" 200a connects internal parts of 
information utility 200 to each other and to outside 
participants, and may also connect outside participants to 
one another. 

Information utility 200 may include a "transaction pro- 
cessor" 200b that processes transactions (to transfer elec- 
tronic funds, for example) based on requests from partici- 
pants and/or report receiver 200e. It may also include a 
"usage analyst" 200c that analyzes reported usage informa- 
tion. A "report creator*' 200c/ may create reports based on 
usage for example, and may provide these reports to outside 
participants and/or to participants within information utility 
200. A "report receiver" 200e may receive reports such as 
usage reports from content users. A "permissioning agent" 
200/ may distribute "rules and controls" granting usage or 
distribution permissions based on a profile of a consumer's 
credit worthiness, for example. An administrator 200A may 
provide information that keeps the virtual distribution envi- 
ronment 100 operating properly. A content and message 
storage 200g may store information for use by participants 
within or outside of information utility 200. 

Example of Distributing "Content" Using A "Chain of 
Handling and Control" 

As explained above, virtual distribution environment 100 
can be used to manage almost any sort of transaction. One 
type of important transaction that virtual distribution envi- 
ronment 100 may be used to manage is the distribution or 
communication of "content" or other important information. 
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FIG. 2 more abstractly shows a "model" of how the FIG. 1 
virtual distribution environment 100 may be used to provide 
a "chain of handling and control" for distributing content. 
Each of the blocks in FIG. 2 may correspond to one or more 

5 of the VDE participants shown in FIG. 1. 

In the FIG. 2 example, a VDE content creator 102 creates 
"content." The content creator 102 may also specify "rules 
and controls" for distributing the content. These 
distribution-related "rules and controls" can specify who has 

10 permission to distribute the rights to use content, and how 
many users are allowed to use the content. 

Arrow 104 shows the content creator 102 sending the 
"rules and controls" associated with the content to a VDE 
rights distributor 106 ("distributor") over an electronic high- 

15 way 108 (or by some other path such as an optical disk sent 
by a delivery service such as U.S. mail). The content can be 
distributed over the same or different path used to send the 
"rules and controls." The distributor 106 generates her own 
"rules and controls" that relate to usage of the content. The 

20 usage-related "rules and controls" may, for example, specify 
what a user can and can't do with the content and how much 
it costs to use the content. These usage-related "rules and 
controls" must be consistent with the "rules and controls" 
specified by content creator 102. 

25 Arrow 110 shows the distributor 106 distributing rights to 
use the content by sending the content's "rules and controls" 
to a content user 112 such as a consumer. The content user 
112 uses the content in accordance with the usage -related 
"rules and controls." 

30 In this FIG. 2 example, information relating to content use 
is, as shown by arrow 114, reported to a financial clearing- 
house 116. Based on this "reporting," the financial clearing- 
house 116 may generate a bill and send it to the content user 
112 over a "reports and payments" network 118. Arrow 120 

35 shows the content user 112 providing payments for content 
usage to the financial clearinghouse 116. Based on the 
reports and payments it receives, the financial clearinghouse 
116 may provide reports and/or payments to the distributor 
106. The distributor 106 may, as shown by arrow 122, 

40 provide reports and/or payments to the content creator 102. 
The clearinghouse 116 may provide reports and payments 
directly to the creator 102. Reporting and/or payments may 
be done differently. For example, clearinghouse 116 may 
directly or through an agent, provide reports and/or pay- 

45 ments to each of VDE content creators 102, and rights 
distributor 106, as well as reports to content user 112. 

The distributor 106 and the content creator 102 may be the 
same person, or they may be different people. For example, 
a musical performing group may act as both content creator 

50 102 and distributor 106 by creating and distributing its own 
musical recordings. As another example, a publishing house 
may act as a distributor 106 to distribute rights to use works 
created by an author content creator 102. Content creators 
102 may use a distributor 106 to efficiently manage the 

55 financial end of content distribution. 

The "financial clearinghouse" 116 shown in FIG. 2 may 
also be a "VDE administrator." Financial clearinghouse 116 
in its VDE administrator role sends "administrative" infor- 
mation to the VDE participants. This administrative infor- 

60 mation helps to keep the virtual distribution environment 
100 operating properly. The "VDE administrator" and finan- 
cial clearinghouse roles may be performed by different 
people or companies, and there can be more than one of 
each. 

65 More about "Rules and Controls" 

The virtual distribution environment 100 prevents use of 
protected information except as permitted by the "rules and 
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controls" (control information). For example, the "rules and 100 also allows "rules and controls" to be delivered sepa- 

controls" shown in FIG. 2 may grant specific individuals or rately from content. Since no one can use or access protected 

classes of content users 112 "permission" to use certain content without "permission" from corresponding "rules and 

content. They may specify what kinds of content usage are controls," the distributor 106 can control use of content that 

permitted, and what kinds are not. They may specify how 5 has already been (or will in the future be) delivered. "Rules 

content usage is to be paid for and how much it costs. As md controls" may be delivered over a path different from the 

another example, "rules and controls" may require content one used for con tent delivery. "Rules and controls" may also 

usage information to be reported back to the distributor 106 be dclivcrcd at somc olhcr ^ nc mntiaA creator 102 

and/or content creator 102 might deliver content to content user 112 over the electronic 

Every VDE partisan in chain of handhng and control highway 108 , or could make the content available to anyone 

is normally subject to rules and controls. Rules and . ^» * . i_ ^ , ^ • 

controls" define the respective rights and obhgations of each °V ^way. Co ^ Q m W b< ; ^ at the tune U 15 

of the various VDE participants "Rules and controls" pro- delivered, or it may be stored for later use or reuse, 

vide information and mechanisms that may establish inter- ™* virtu / 1 distnbuUon environment 100 also allows 

dependencies and relationships between the participants. payment and reporUng means to be dehvered separately. For 

"Rules and controls" are flexible, and permit "virtual dis- 15 example, the content user 112 may have a virtual "credit 

tribution environment" 100 to support most "traditional" card " mat extends credit (up to a certain limit) to pay for 

business transactions. For example: usage of any content. A "credit transaction" can take place 

"Rules and controls" may specify which financial at the user's site without requiring any "online" connection 

clearinghouse^) 116 may process payments, or further authorization. This invention can be used to help 

"Rules and controls" may specify which participants) 2° securely protect the virtual "credit card" against unautho- 

receive what kind of usage report, and rized use. 

"Rules and controls" may specify that certain information "Rules and Contents" Define Processes 

is revealed to certain participants, and that other infor- FIG. 3 shows an example of an overall process based on 

mation is kept secret from mem, "rules and controls." It includes an "events" process 402, a 

"Rules and controls" may self limit if and how they may 25 meter process 404, a billing process 406, and a budget 

be changed. Often, "rules and controls" specified by one process 408. Not all of the processes shown in FIG. 3 will 

VDE participant cannot be changed by another VDE par- be used for every set of "rules and controls." 

ticipant. For example, a content user 112 generally can't The "events process" 402 detects things that happen 

change "rules and controls" specified by a distributor 106 ("events") and determines which of those "events" need 

that require the user to pay for content usage at a certain rate. 30 action by the other "processes." The "events" may include, 

"Rules and controls" may "persist" as they pass through a for example, a request to use content or generate a usage 

"chain of handling and control," and may be "inherited" as permission. Some events may need additional processing, 

they are passed down from one VDE participant to the next. and others may not. Whether an "event" needs more pro- 

Depending upon their needs, VDE participants can cessing depends on the "rules and controls" corresponding 

specify that their "rules and controls" can be changed under 35 to the content. For example, a user who lacks permission 

conditions specified by the same or other "rules and con- will not have her request satisfied ("No Go'*). As another 

trols." For example, "rules and controls" specified by the example, each user request to turn to a new page of an 

content creator 102 may permit the distributor 106 to "mark electronic book may be satisfied ("Go"), but it may not be 

up" the usage price just as retail stores "mark up" the necessary to meter, bill or budget those requests. A user who 

wholesale price of goods. FIG. 2A shows an example in 40 has purchased a copy of a novel may be permitted to open 

which certain "rules and controls" persist unchanged from and read the novel as many times as she wants to without any 

content creator 102 to content user 112; other "rules and further metering, billing or budge ting. In this simple 

controls" are modified or deleted by distributor 106; and still example, the "event process" 402 may request metering, 

other "rules and controls" are added by the distributor. billing and/or budgeting processes the first time the user asks 

"Rules and controls" can be used to protect the content 45 to open the protected novel (so the purchase price can be 

user's privacy by limiting the information that is reported to charged to the user), and treat all later requests to open the 

other VDE participants. As one example, "rules and con- same novel as "insignificant events." Other content (for 

trols" can cause content usage information to be reported example, searching an electronic telephone directory) may 

anonymously without revealing content user identity, or it require the user to pay a fee for each access, 

can reveal only certain information to certain participants 50 "Meter" process 404 keeps track of events, and may 

(for example, information derived from usage) with appro- report usage to distributor 106 and/or other appropriate VDE 

priate permission, if required. This ability to securely control participants). FIG. 4 shows that process 404 can be based 

what information is revealed and what VDE participant(s) it on a number of different factors such as: 

is revealed to allows the privacy rights of all VDE partici- ( a ) tV p e 0 f t0 charge for, 

pants to be protected. 55 (b) what ^ of ^ tQ base ch ^ 

Rules and Contents Can Be Separately Dehvered ' 

As mentioned above, virtual distribution environment 100 ( c > how much 10 char 8 e P er umt > 

"associates" content with corresponding "rules and ( d ) when 10 report, and 

controls," and prevents the content from being used or (e) how to pay. 

accessed unless a set of corresponding "rules and controls" 60 These factors may be specified by the "rules and controls" 

is available. The distributor 106 doesn't need to deliver that control the meter process. 

content to control the content's distribution. The preferred Billing process 406 determines how much to charge for 

embodiment can securely protect content by protecting events. It records and reports payment information, 

corresponding, usage enabling "rules and controls" against Budget process 408 limits how much content usage is 

unauthorized distribution and use. 65 permitted. For example, budget process 408 may limit the 

In some examples, "rules and controls" may travel with number of times content may be accessed or copied, or it 

the content they apply to. Virtual distribution environment may limit the number of pages or other amount of content 
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that can be used based on, for example, the number of ods 1000 may record the identity of anyone who opens the 

dollars available in a credit account. Budget process 408 electronic container 302, and can also control how informa- 

records and reports financial and other transaction in forma- tion content is to be charged based on "metering." Methods 

tion associated with such limits. 1000 may apply to one or several different information 

Content may be supplied to the user once these processes s contents 304 and associated containers 302, as well as to all 

have been successfully performed. or portions of information content 304. 

Containers and "Objects" Secure ftp^ing Unit (SPU) 

FIG. 5A shows how the virtual distribution environment ^ < iyDE partic ip ants » may each have an "electronic 

100, in a preferred embodiment, may package information appliance." The appliance may be or coDtain a computer, 

elements (content) into a "container" 302 so the information 10 ^ a p pliaiiccs may communicate over the electronic high- 

can't be accessed except as provided by its "rules and way 108. FIG. 6 shows a secure processing unit ("SPU") 500 

controls." Normally, the container 302 is electronic rather portion of the "electronic appliance" used in this example by 

than physical. Electronic container 302 in one example each VD£ participant. SPU 500 processes information in a 

comprises "digital" information having a well defined struc- secure proce ssing environment 503, and stores important 

hire. Container 302 and its contents can be called an "object 15 mformation seC urely. SPU 500 may be emulated by software 

operating in a host electronic appliance. 

The FIG. 5A example shows items "within" and enclosed spu 500 ^ enclosed within and protected by a "tamper 
by container 302. However, container 302 may "contain" resistant barrier ~ 502 Security barrier 502 separates 
items without those items actually being stored within the mc secure environment 503 from the rest of the world. It 
container. For example, the container 302 may reference 20 prevents ^0^^ proce sses within the secure envi- 
items that are available elsewhere such as in other containers ronment 503 from being obscrvc d, interfered with and 
at remote sites. Container 302 may reference items available leaving except under appropr i a te secure conditions. Barrier 
at different times or only during limited times. Some items 502 ^ cont^ external access to secure resources, pro- 
may be too large to store within container 302. Items may, cesses and in f orma tion within SPU 500. In one example, 
for example, be delivered to the user in the form of a "live 25 tamper resistant security 5arrier 502 ^ formed by 
feed" of video at a certain time. Even then, the container 302 features such as "encryption," and hardware that detects 
"contains" the live feed (by reference) in this example. tampering and/or destroys sensitive information within 

Container 302 may contain information content 304 in secure environment 503 when tampering is detected, 

electronic (such as "digital") form. Information content 304 spu 500 m mis example ^ an integrated circuit ("IC") 

could be the text of a novel, a picture, sound such as a 30 « chip » 504 including "hardware" 506 and "firmware" 508. 

musical performance or a reading, a movie or other video, spu 500 connects to the rest of the electronic appliance 

computer software, or just about any other kind of electronic m « applia nce link" 510. SPU "firmware" 508 in this 

information you can think of. Other types of "objects" 300 example is "software" such as a "computer program(s)" 

(such as "administrative objects") may contain "administra- « cmbc dded" within chip 504. Firmware 508 makes the 

tive" or other information instead of or in addition to 3S hardw are 506 work. Hardware 506 preferably contains a 

information content 304 processor to perform instructions specified by firmware 508. 

In the FIG. 5A example, container 302 may also contain "Hardware" 506 also contains long-term and short-term 

"rules and controls" in the form of: memories to store information securely so it can't be tarn- 

(a) a "permissions record" 808; pere d w jth, SPU 500 may also have a protected clock/ 

(b) "budgets" 308; and 4 o calendar used for timing events. The SPU hardware 506 in 

(c) "other methods" 1000. this example may include special purpose electronic circuits 
FIG. 5B gives some additional detail about permissions that are specially designed to perform certain processes 

record 808, budgets 308 and other methods 1000. The (such as "encryption" and "decryption") rapidly and eflfi- 

"permissions record" 808 specifies the rights associated with ciently, 

the object 300 such as, for example, who can open the 45 The particular context in which SPU 500 is being used 
container 302, who can use the object's contents, who can will determine how much processing capabilities SPU 500 
distribute the object, and what other control mechanisms should have. SPU hardware 506, in this example, provides 
must be active. For example, permissions record 808 may at least enough processing capabilities to support the secure 
specify a user's rights to use, distribute and/or administer the parts of processes shown in FIG. 3. In some contexts, the 
container 302 and its content. Permissions record 808 may 50 functions of SPU 500 may be increased so the SPU can 
also specify requirements to be applied by the budgets 308 perform all the electronic appliance processing, and can be 
and "other methods" 1000. Permissions record 808 may also incorporated into a general purpose processor. In other 
contain security related information such as scrambling and contexts, SPU 500 may work alongside a general purpose 
descrambling "keys." processor, and therefore only needs to have enough process- 
budgets" 308 shown in FIG. 5B are a special type of 55 ing capabilities to handle secure processes, 
"method" 1000 that may specify, among other things, limi- VDE Electronic Appliance and "Rights Operating Sys- 
tations on usage of information content 304, and how usage tem" 

will be paid for. Budgets 308 can specify, for example, how FIG. 7 shows an example of an electronic appliance 600 

much of the total information content 304 can be used and/or including SPU 500. Electronic appliance 600 may be prac- 

copied. The methods 310 may prevent use of more than the 60 tically any kind of electrical or electronic device, such as: 

amount specified by a specific budget. a computer 

"Other methods" 1000 define basic operations used by a TV. "set top" control box 
"rules and controls." Such "methods" 1000 may include, for 

example, how usage is to be "metered," if and how content a ^ B ^ CT , 

304 and other information is to be scrambled and 65 a tcle P nonc 

descrambled, and other processes associated with handling a sound system 

and controlling information content 304. For example, meth- a video reproduction system 
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a video game player 

a "smart" credit card 
Electronic appliance 600 in this example may include a 
keyboard or keypad 612, a voice recognizer 613, and a 
display 614. A human user can input commands through 5 
keyboard 612 and/or voice recognizer 613, and may view 
information on display 614. Appliance 600 may communi- 
cate with the outside world through any of the connections/ 
devices normally used within an electronic appliance. The 
connections/devices shown along the bottom of the drawing io 
are examples: 

a "modem" 618 or other telecommunications link; 

a CD ROM disk 620 or other storage medium or device; 

a printer 622; 15 

broadcast reception 624; 

a document scanner 626; and 

a "cable" 628 connecting the appliance with a "network." 

Virtual distribution environment 100 provides a "rights 
operating system" 602 that manages appliance 600 and SPU 20 
500 by controlling their hardware resources. The operating 
system 602 may also support at least one "application" 608. 
Generally, "application" 608 is hardware and/or software 
specific to the context of appliance 600. For example, if 
appliance 600 is a personal computer, then "application" 608 25 
could be a program loaded by the user, for instance, a word 
processor, a communications system or a sound recorder. If 
appliance 600 is a television controller box, then application 
608 might be hardware or software that allows a user to 
order videos on demand and perform other functions such as 30 
fast forward and rewind. In this example, operating system 
602 provides a standardized, well defined, generalized 
"interface" that could support and work with many different 
"applications" 608. 

Operating system 602 in this example provides "rights 35 
and auditing operating system functions" 604 and "other 
operating system functions" 606. The "rights and auditing 
operating system functions" 604 securely handle tasks that 
relate to virtual distribution environment 100. SPU 500 
provides or supports many of the security functions of the 40 
"rights and auditing operating system functions" 402. The 
"other operating system functions" 606 handle general 
appliance functions. Overall operating system 602 may be 
designed from the beginning to include the "rights and 
auditing operating system functions" 604 plus the "other 45 
operating system functions" 606, or the "rights and auditing 
operating system functions" may be an add-on to a preex- 
isting operating system providing the "other operating sys- 
tem functions." 

"Rights operating system" 602 in this example can work 50 
with many different types of appliances 600. For example, it 
can work with large mainframe computers, "minicomput- 
ers" and "microcomputers" such as personal computers and 
portable computing devices. It can also work in control 
boxes on the top of television sets, small portable "pagers," 55 
desktop radios, stereo sound systems, telephones, telephone 
switches, or any other electronic appliance. This ability to 
work on big appliances as well as little appliances is called 
"scalable." A "scalable" operating system 602 means that 
there can be a standardized interface across many different 60 
appliances performing a wide variety of tasks. 

The "rights operating system functions" 604 are 
"services-based" in this example. For example, "rights oper- 
ating system functions" 604 handle summary requests from 
application 608 rather than requiring the application to 65 
always make more detailed "subrequests" or otherwise get 
involved with the underlying complexities involved in sat- 
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isfying a summary request. For example, application 608 
may simply ask to read specified information; "rights oper- 
ating system functions" 604 can then decide whether the 
desired information is VDE-protected content and, if it is, 
perform processes needed to make the information avail- 
able. This feature is called "transparency." "Transparency " 
makes tasks easy for the application 608. "Rights operating 
system functions" 604 can support applications 608 that 
"know" nothing about virtual distribution environment 100. 
Applications 608 that are "aware" of virtual distribution 
environment 100 may be able to make more detailed use of 
virtual distribution environment 100. 

In this example, "rights operating system functions" 604 
are "event driven". Rather than repeatedly examining the 
state of electronic appliance 600 to determine whether a 
condition has arisen, the "rights operating system functions" 
604 may respond directly to "events" or "happenings" 
within appliance 600. 

In this example, some of the services performed by "rights 
operating system functions" 604 may be extended based on 
additional "components" delivered to operating system 602. 
"Rights operating system functions" 604 can collect together 
and use "components" sent by different participants at 
different times. The "components" help to make the oper- 
ating system 602 "scalable." Some components can change 
how services work on little appliances versus how they work 
on big appliances (e.g., multi-user). Other components are 
designed to work with specific applications or classes of 
applications (e.g., some types of meters and some types of 
budgets). 

Electronic Appliance 600 

An electronic appliance 600 provided by the preferred 
embodiment may, for example, be any electronic apparatus 
that contains one or more microprocessors and/or microcon- 
trollers and/or other devices which perform logical and/or 
mathematical calculations. This may include computers; 
computer terminals; device controllers for use with comput- 
ers; peripheral devices for use with computers; digital dis- 
play devices; televisions; video and audio/video projection 
systems; channel selectors and/or decoders for use with 
broadcast and/or cable transmissions; remote control 
devices; video and/or audio recorders; media players includ- 
ing compact disc players, videodisc players and tape play- 
ers; audio and/or video amplifiers; virtual reality machines; 
electronic game players; multimedia players; radios; tele- 
phones; videophones; facsimile machines; robots; numeri- 
cally controlled machines including machine tools and the 
like; and other devices containing one or more microcom- 
puters and/or microcontrollers and/or other CPUs, including 
those not yet in existence. 

FIG. 8 shows an example of an electronic appliance 600. 
This example of electronic appliance 600 includes a system 
bus 653. In this example, one or more conventional general 
purpose central processing units ("CPUs") 654 are con- 
nected to bus 653. Bus 653 connects CPU(s) 654 to RAM 
656, ROM 658, and I/O controller 660. One or more SPUs 
500 may also be connected to system bus 653. System bus 
653 may permit SPU(s) 500 to communicate with CPU(s) 
654, and also may allow both the CPU(s) and the SPU(s) to 
communicate (e.g., over shared address and data lines) with 
RAM 656, ROM 658 and I/O controller 660. Apower supply 
659 may provide power to SPU 500, CPU 654 and the other 
system components shown. 

In the example shown, I/O controller 660 is connected to 
secondary storage device 652, a keyboard/display 612, 614, 
a communications controller 666, and a backup storage 
device 668. Backup storage device 668 may, for example, 
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store information on mass media such as a tape 670, a floppy 
disk, a removable memory card, etc. Communications con- 
troller 666 may allow electronic appliance 600 to commu- 
nicate with other electronic appliances via network 672 or 
other telecommunications links. Different electronic appli- 5 
ances 600 may interoperate even if they use different CPUs 
and different instances of ROS 602, so long as they typically 
use compatible communication protocols and/or security 
methods. In this example, I/O controller 660 permits CPU 
654 and SPU 500 to read from and write to secondary no 
storage 662, keyboard/display 612, 614, communications 
controller 666, and backup storage device 668. 

Secondary storage 662 may comprise the same one or 
more non-secure secondary storage devices (such as a 
magnetic disk and a CD-ROM drive as one example) that 15 
electronic appliance 600 uses for general secondary storage 
functions. In some implementations, part or all of secondary 
storage 652 may comprise a secondary storage device(s) that 
is physically enclosed within a secure enclosure. However, 
since it may not be practical or cost-effective to physically 20 
secure secondary storage 652 in many implementations, 
secondary storage 652 may be used to store information in 
a secure manner by encrypting information before storing it 
in secondary storage 652. If information is encrypted before 
it is stored, physical access to secondary storage 652 or its 25 
contents does not readily reveal or compromise the infor- 
mation. 

Secondary storage 652 in this example stores code and 
data used by CPU 654 and/or SPU 500 to control the overall 
operation of electronic appliance 600. For example, FIG. 8 30 
shows that "Rights Operating System" ("ROS") 602 
(including a portion 604 of ROS that provides VDE func- 
tions and a portion 606 that provides other OS functions) 
shown in FIG. 7 may be stored on secondary storage 652. 
Secondary storage 652 may also store one or more VDE 35 
objects 300. FIG. 8 also shows that the secure files 610 
shown in FIG. 7 may be stored on secondary storage 652 in 
the form of a "secure database 5 ' or management file system 
610. This secure database 610 may store and organize 
information used by ROS 602 to perform VDE functions 40 
604. Thus, the code that is executed to perform VDE and 
other OS functions 604, 606, and secure files 610 (as well as 
VDE objects 300) associated with those functions may be 
stored in secondary storage 652. Secondary storage 652 may 
also store "other information" 673 such as, for example, 45 
information used by other operating system functions 606 
for task management, non-VDE files, etc. Portions of the 
elements indicated in secondary storage 652 may also be 
stored in ROM 658, so long as those elements do not require 
changes (except when ROM 658 is replaced). Portions of 50 
ROS 602 in particular may desirably be included in ROM 
658 (e.g., "bootstrap" routines, POST routines, etc. for use 
in establishing an operating environment for electronic 
appliance 600 when power is applied). 

FIG. 8 shows that secondary storage 652 may also be used 55 
to store code ("application programs") providing user 
application(s) 608 shown in FIG. 7. FIG. 8 shows that there 
may be two general types of application programs 608: 
"VDE aware" applications 608a, and Non-VDE aware 
applications 608b. VDE aware applications 608a may have 60 
been at least in part designed specifically with VDE 100 in 
mind to access and take detailed advantage of VDE func- 
tions 604. Because of the "transparency" features of ROS 
602, non-VDE aware applications 6086 (e.g., applications 
not specifically designed for VDE 100) can also access and 65 
take advantage of VDE functions 604. 

Secure Processing Unit 500 
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Each VDE node or other electronic appliance 600 in the 
preferred embodiment may include one or more SPUs 500. 
SPUs 500 may be used to perform all secure processing for 
VDE 100, For example, SPU 500 is used for decrypting (or 
otherwise unsecuring) VDE protected objects 300. It is also 
used for managing encrypted and/or otherwise secured com- 
munication (such as by employing authentication and/or 
error-correction validation of information). SPU 500 may 
also perform secure data management processes including 
governing usage of, auditing of, and where appropriate, 
payment for VDE objects 300 (through the use of 
prepayments, credits, real-time electronic debits from bank 
accounts and/or VDE node currency token deposit 
accounts). SPU 500 may perform other transactions related 
to such VDE objects 300. 
SPU Physical Packaging and Security Barrier 502 
As shown FIG. 6, in the preferred embodiment, an SPU 
500 may be implemented as a single integrated circuit 
"chip" 505 to provide a secure processing environment in 
which confidential and/or commercially valuable informa- 
tion can be safely processed, encrypted and/or decrypted. IC 
chip 505 may, for example, comprise a small semiconductor 
"die" about the size of a thumbnail. This semiconductor die 
may include semiconductor and metal conductive pathways. 
These pathways define the circuitry, and thus the 
functionality, of SPU 500. Some of these pathways are 
electrically connected to the external "pins" 504 of the chip 
505. 

As shown in FIGS. 6 and 9, SPU 500 may be surrounded 
by a tamper-resistant hardware security barrier 502. Part of 
this security barrier 502 is formed by a plastic or other 
package in which an SPU "die" is encased. Because the 
processing occurring within, and information stored by, SPU 
500 are not easily accessible to the outside world, they are 
relatively secure from unauthorized access and tampering. 
All signals cross barrier 502 through a secure, controlled 
path provided by BIU 530 that restricts the outside world's 
access to the internal components within SPU 500. This 
secure, controlled path resists attempts from the outside 
world to access secret information and resources within SPU 
500. 

It is possible to remove the plastic package of an IC chip 
and gain access to the "die." It is also possible to analyze and 
"reverse engineer" the "die" itself (e.g., using various types 
of logic analyzers and microprobes to collect and analyze 
signals on the die while the circuitry is operating, using acid 
etching or other techniques to remove semiconductor layers 
to expose other layers, viewing and photographing the die 
using an electron microscope, etc.) Although no system or 
circuit is absolutely impervious to such attacks, SPU barrier 
502 may include additional hardware protections that make 
successful attacks exceedingly costly and time consuming. 
For example, ion implantation and/or other fabrication tech- 
niques may be used to make it very difficult to visually 
discern SPU die conductive pathways, and SPU internal 
circuitry may be fabricated in such a way that it "self- 
destructs" when exposed to air and/or light. SPU 500 may 
store secret information in internal memory that loses its 
contents when power is lost. Circuitry may be incorporated 
within SPU 500 that detects microprobing or other 
tampering, and self-destructs (or destroys other parts of the 
SPU) when tampering is detected. These and other 
hardware-based physical security techniques contribute to 
tamper- resistant hardware security barrier 502. 

To increase the security of security barrier 502 even 
further, it is possible to encase or include SPU 500 in one or 
more further physical enclosures such as, for example: 
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epoxy or other "potting compound**; further module enclo- 
sures including additional self-destruct, self-disabling or 
other features activated when tampering is detected; further 
modules providing additional security protections such as 
requiring password or other authentication to operate; and 5 
the like. In addition, further layers of metal may be added to 
the die to complicate acid etching, micro probing, and the 
like; circuitry designed to "zeroize** memory may be 
included as an aspect of self-destruct processes; the plastic 
package itself may be designed to resist chemical as well as 10 
physical "attacks"; and memories internal to SPU 500 may 
have specialized addressing and refresh circuitry that 
"shuffles*' the location of bits to complicate efforts to elec- 
trically determine the value of memory locations. These and 
other techniques may contribute to the security of barrier 15 
502. 

In some electronic appliances 600, SPU 500 may be 
integrated together with the device microcontroller or 
equivalent or with a device I/O or communications micro- 
controller into a common chip (or chip set) 505. For 20 
example, in one preferred embodiment, SPU 500 may be 
integrated together with one or more other CPU(s) (e.g., a 
CPU 654 of an electronic appliance) in a single component 
or package. The other CPU(s) 654 may be any centrally 
controlling logic arrangement, such as for example, a 25 
microprocessor, other microcontroller, and/or array or other 
parallel processor. This integrated configuration may result 
in lower overall cost, smaller overall size, and potentially 
faster interaction between an SPU 500 and a CPU 654. 
Integration may also provide wider distribution if an inte- 30 
grated SPU/CPU component is a standard feature of a 
widely distributed microprocessor line. Merging an SPU 
500 into a main CPU 654 of an electronic appliance 600 (or 
into another appliance or appliance peripheral microcom- 
puter or other microcontroller) may substantially reduce the 35 
overhead cost of implementing VDE 100. Integration con- 
siderations may include cost of implementation, cost of 
manufacture, desired degree of security, and value of com- 
pactness. 

SPU 500 may also be integrated with devices other than 40 
CPUs. For example, for video and multimedia applications, 
some performance and/or security advantages (depending 
on overall design) could result from integrating an SPU 500 
into a video controller chip or chipset. SPU 500 can also be 
integrated directly into a network communications chip or 45 
chipset or the like. Certain performance advantages in high 
speed communications applications may also result from 
integrating an SPU 500 with a modem chip or chipset. This 
may facilitate incorporation of an SPU 500 into communi- 
cation appliances such as stand-alone fax machines. SPU 50 
500 may also be integrated into other peripheral devices, 
such as CD-ROM devices, set-top cable devices, game 
devices, and a wide variety of other electronic appliances 
that use, allow access to, perform transactions related to, or 
consume, distributed information. 55 

SPU 500 Internal Architecture 

FIG. 9 is a detailed diagram of the internal structure 
within an example of SPU 500. SPU 500 in this example 
includes a single microprocessor 520 and a limited amount 
of memory configured as ROM 532 and RAM 534. In more 60 
detail, this example of SPU 500 includes microprocessor 
520, an encrypt/decrypt engine 522, a DMA controller 526, 
a real-time clock 528, a bus interface unit ("BIU") 530, a 
read only memory (ROM) 532, a random access memory 
(RAM) 534, and a memory management unit ("MMU") 540. 65 
DMA controller 526 and MMU 540 are optional, but the 
performance of SPU 500 may suffer if they are not present. 
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SPU 500 may also include an optional pattern matching 
engine 524, an optional random number generator 542, an 
optional arithmetic accelerator circuit 544, and optional 
compression/decompression circuit 546. A shared address/ 
data bus arrangement 536 may transfer information between 
these various components under control of microprocessor 
520 and/or DMA controller 526. Additional or alternate 
dedicated paths 538 may connect microprocessor 520 to the 
other components (e.g., encrypt/decrypt engine 522 via line 
538a, real-time clock 528 via line 538/?, bus interface unit 
530 via line 538c, DMA controller via line 538*/, and 
memory management unit (MMU) 540 via line 538e). 

The following section discusses each of these SPU com- 
ponents in more detail. 

Microprocessor 520 

Microprocessor 520 is the "brain" of SPU 500. In this 
example, it executes a sequence of steps specified by code 
stored (at least temporarily) within ROM 532 and/or RAM 
534. Microprocessor 520 in the preferred embodiment com- 
prises a dedicated central processing arrangement (e.g., a 
RISC and/or CISC processor unit, a microcontroller, and/or 
other central processing means or, less desirably in most 
applications, process specific dedicated control logic) for 
executing instructions stored in the ROM 532 and/or other 
memory. Microprocessor 520 may be separate elements of a 
circuitry layout, or may be separate packages within a secure 
SPU 500. 

In the preferred embodiment, microprocessor 520 nor- 
mally handles the most security sensitive aspects of the 
operation of electronic appliance 600. For example, micro- 
processor 520 may manage VDE decrypting, encrypting, 
certain content and/or appliance usage control information, 
keeping track of usage of VDE secured content, and other 
VDE usage control related functions. 

Stored in each SPU 500 and/or electronic appliance 
secondary memory 652 may be, for example, an instance of 
ROS 602 software, application programs 608, objects 300 
containing VDE controlled property content and related 
information, and management database 610 that stores both 
information associated with objects and VDE control infor- 
mation. ROS 602 includes software intended for execution 
by SPU microprocessor 520 for, in part, controlling usage of 
VDE related objects 300 by electronic appliance 600. As 
will be explained, these SPU programs include "load mod- 
ules" for performing basic control functions. These various 
programs and associated data are executed and manipulated 
primarily by microprocessor 520. 

Real Time Clock (RTC) 528 

In the preferred embodiment, SPU 500 includes a real 
time clock circuit ("RTC") 528 that serves as a reliable, 
tamper resistant time base for the SPU. RTC 528 keeps track 
of time of day and date (e.g., month, day and year) in the 
preferred embodiment, and thus may comprise a combina- 
tion calendar and clock. A reliable time base is important for 
implementing time based usage metering methods, "time 
aged decryption keys," and other time based SPU functions. 

The RTC 528 must receive power in order to operate. 
Optimally, the RTC 528 power source could comprise a 
small battery located within SPU 500 or other secure enclo- 
sure. However, the RTC 528 may employ a power source 
such as an externally located battery that is external to the 
SPU 500. Such an externally located battery may provide 
relatively uninterrupted power to RTC 528, and may also 
maintain as non-volatile at least a portion of the otherwise 
volatile RAM 534 within SPU 500. 

In one implementation, electronic appliance power supply 
659 is also used to power SPU 500. Using any external 
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power supply as the only power source for RTC 528 may 
significantly reduce the usefulness of time based security 
techniques unless, at minimum, SPU 500 recognizes any 
interruption (or any material interruption) of the supply of 
external power, records such interruption, and responds as 5 
may be appropriate such as disabling the ability of the SPU 
500 to perform certain or all VDE processes. Recognizing a 
power interruption may, for example, be accomplished by 
employing a circuit which is activated by power failure. The 
power failure sensing circuit may power another circuit that 10 
includes associated logic for recording one or more power 
fail events. Capacitor discharge circuitry may provide the 
necessary temporary power to operate this logic. In addition 
or alternatively, SPU 500 may from time to time compare an 
output of RTC 528 to a clock output of a host electronic 15 
appliance 600, if available. In the event a discrepancy is 
detected, SPU 500 may respond as appropriate, including 
recording the discrepancy and/or disabling at least some 
portion of processes performed by SPU 500 under at least 
some circumstances 20 

If a power failure and/or RTC 528 discrepancy and/or 
other event indicates the possibility of tampering, SPU 500 
may automatically destroy, or render inaccessible without 
privileged intervention, one or more portions of sensitive 
information it stores, such as execution related information 25 
and/or encryption key related information. To provide fur- 
ther SPU operation, such destroyed information would have 
to be replaced by a VDE clearinghouse, administrator and/or 
distributor, as may be appropriate. This may be achieved by 
remotely downloading update and/or replacement data and/ 30 
or code. In the event of a disabling and/or destruction of 
processes and/or information as described above, the elec- 
tronic appliance 600 may require a secure VDE communi- 
cation with an administrator, clearinghouse, and/or distribu- 
tor as appropriate in order to reinitialize the RTC 528. Some 35 
or all secure SPU 500 processes may not operate until then. 

It may be desirable to provide a mechanism for setting 
and/or synchronizing RTC 528. In the preferred 
embodiment, when communication occurs between VDE 
electronic appliance 600 and another VDE appliance, an 40 
output of RTC 528 may be compared to a controlled RTC 
528 output time under control of the party authorized to be 
"senior" and controlling. In the event of a discrepancy, 
appropriate action may be taken, including resetting the RTC 
528 of the "junior" controlled participant in the communi- 45 
cation. 

SPU Encrypt/Decrypt Engine 522 

In the preferred embodiment, SPU encrypt/decrypt engine 
522 provides special purpose hardware (e.g., a hardware 
state machine) for rapidly and efficiently encrypting and/or 50 
decrypting data. In some implementations, the encrypt/ 
decrypt functions may be performed instead by micropro- 
cessor 520 under software control, but providing special 
purpose encrypt/decrypt hardware engine 522 will, in 
general, provide increased performance. Microprocessor 55 
520 may, if desired, comprise a combination of processor 
circuitry and dedicated encryption/decryption logic that may 
be integrated together in the same circuitry layout so as to, 
for example, optimally share one or more circuit elements. 

Generally, it is preferable that a computationally efficient 60 
but highly secure "bulk" encryption/decryption technique 
should be used to protect most of the data and objects 
handled by SPU 500. It is preferable that an extremely 
secure encryption/decryption technique be used as an aspect 
of authenticating the identity of electronic appliances 600 65 
that are establishing a communication channel and securing 
any transferred permission, method, and administrative 
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information. In the preferred embodiment, the encrypt/ 
decrypt engine 522 includes both a symmetric key 
encryption/decryption circuit (e.g. DES, Skipjack/Clipper, 
IDEA, RC-2, RC-4, etc.) and an antisymmetric 
(asymmetric) or Public Key ("PK") encryption/decryption 
circuit The public/private key encryption/decryption circuit 
is used principally as an aspect of secure communications 
between an SPU 500 and VDE administrators, or other 
electronic appliances 600, that is between VDE secure 
subsystems. Asymmetric encryption/decryption circuit may 
be used for "bulk" encrypting and decrypting most data 
stored in secondary storage 662 of electronic appliance 600 
in which SPU 500 resides. The symmetric key encryption/ 
decryption circuit may also be used for encrypting and 
decrypting content stored within VDE objects 300. 

DES or public/private key methods may be used for all 
encryption functions. In alternate embodiments, encryption 
and decryption methods other than the DES and public/ 
private key methods could be used for the various encryp- 
tion related functions. For instance, other types of symmetric 
encryption/decryption techniques in which the same key is 
used for encryption and decryption could be used in place of 
DES encryption and decryption. The preferred embodiment 
can support a plurality of decryption/encryption techniques 
using multiple dedicated circuits within encrypt/decrypt 
engine 522 and/or the processing arrangement within SPU 
500. 

Pattern Matching Engine 524 

Optional pattern matching engine 524 may provide spe- 
cial purpose hardware for performing pattern matching 
functions. One of the functions SPU 500 may perform is to 
validate/authenticate VDE objects 300 and other items. 
Validation/authentication often involves comparing long 
data strings to determine whether they compare in a prede- 
termined way. In addition, certain forms of usage (such as 
logical and/or physical (contiguous) relatedness of accessed 
elements) may require searching potentially long strings of 
data for certain bit patterns or other significant pattern 
related metrics. Although pattern matching can be per- 
formed by SPU microprocessor 520 under software control, 
providing special purpose hardware pattern matching engine 
524 may speed up the pattern matching process. 

Compression/Decompression Engine 546 

An optional compression/decompression engine 546 may 
be provided within an SPU 500 to, for example, compress 
and/or decompress content stored in, or released from, VDE 
objects 300. Compression/decompression engine 546 may 
implement one or more compression algorithms using hard- 
ware circuitry to improve the performance of compression/ 
decompression operations that would otherwise be per- 
formed by software operating on microprocessor 520, or 
outside SPU 500. Decompression is important in the release 
of data such as video and audio that is usually compressed 
before distribution and whose decompression speed is 
important. In some cases, information that is useful for 
usage monitoring purposes (such as record separators or 
other delimiters) is "hidden" under a compression layer that 
must be removed before this information can be detected 
and used inside SPU 500. 

Random Number Generator 542 

Optional random number generator 542 may provide 
specialized hardware circuitry for generating random values 
(e.g., from inherently unpredictable physical processes such 
as quantum noise). Such random values are particularly 
useful for constructing encryption keys or unique identifiers, 
and for initializing the generation of pseudo-random 
sequences. Random number generator 542 may produce 
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values of any convenient length, including as small as a SPU Memory Architecture 

single bit per use. A random number of arbitrary size may be In the preferred embodiment, SPU 500 uses three general 

constructed by concatenating values produced by random kinds of memory: 

number generator 542. A cryptographically strong pseudo- (1) internal ROM 532; 

random sequence may be generated from a random key and 5 (2) internal RAM 534; and 

seed generated with random number generator 542 and (3) external memory (typically RAM and/or disk supplied 

repeated encryption either with the encrypt/decrypt engine by a host electronic appliance). 

522 or cryptographic algorithms in SPU 500. Such The internal ROM 532 and RAM 534 within SPU 500 

sequences may be used, for example, in private headers to provide a secure operating environment and execution 

frustrate efforts to determine an encryption key through 10 space. Because of cost limitations, chip fabrication size, 

cryptoanalysis. complexity and other limitations, it may not be possible to 

Arithmetic Accelerator 544 provide sufficient memory within SPU 500 to store all 

An optional arithmetic accelerator 544 may be provided information that an SPU needs to process in a secure 

within an SPU 500 in the form of hardware circuitry that can ^j^' £ u Al?« ! ^ aicdi J™* 5 amount of ROM 

rapidly perform mathematical calculations such as multipli- 15 ^ . b ° mduded Wlthm S? V 5 °' 

cation and exponentiation involving large numbers. These S ™ 500 ^ s f xc "^formation in memory external to it 

i it' c i u , j , . and move this information into and out of its secure internal 

calculations can, for example, be requested by microproces- , , , . T iL 

w , r / . ,„ ' . ... memory space on an as needed basis. In these cases, secure 

sor 520 or encrypt/decrypt engine 522, to assist in the process ^ g % le s performed by an SPU typically must be 

computations required for certain asymmetric encryption/ segmented ^ small) packaged elements that may 

decryption operations. Such arithmetic accelerators are well- 20 be « paged ^ and « paged out « of me limiled available 

known to those skilled in the art. In some implementations, internal memory space. Memory external to an SPU 500 

a separate arithmetic accelerator 544 may be omitted and may not be secure. Since the external memory may not be 

any necessary calculations may be performed by micropro- secure, SPU 500 may encrypt and cryptographically seal 

cessor 520 under software control. code and other information before storing it in external 

DMA Controller 526 25 memory. Similarly, SPU 500 must typically decrypt code 

DMA controller 526 controls information transfers over and other information obtained from external memory in 

address/data bus 536 without requiring microprocessor 520 encrypted form before processing (e.g., executing) based on 

to process each individual data transfer. Typically, micro- it. In the preferred embodiment, there are two general 

processor 520 may write to DMA controller 526 target and approaches used to address potential memory limitations in 

destination addresses and the number of bytes to transfer, 30 a SPU 500. In the first case, the small, securely packaged 

and DMA controller 526 may then automatically transfer a elements represent information contained in secure database 

block of data between components of SPU 500 (e.g., from 610. In the second case, such elements may represent 

ROM 532 to RAM 534, between encrypt/decrypt engine 522 protected (e.g., encrypted) virtual memory pages. Although 

and RAM 534, between bus interface unit 530 and RAM virtual memory pages may correspond to information ele- 

534, etc.). DMA controller 526 may have multiple channels 35 ments stored in secure database 610, this is not required in 

to handle multiple transfers simultaneously. In some this example of a SPU memory architecture, 

implementations, a separate DMA controller 526 may be The following is a more detailed discussion of each of 

omitted, and any necessary data movements may be per- these three SPU memory resources, 

formed by microprocessor 520 under software control. SPU Internal ROM 

Bus Interface Unit (BIU) 530 40 SPU 500 read only memory (ROM) 532 or comparable 
Bus interface unit (BIU) 530 communicates information purpose device provides secure internal non-volatile storage 
between SPU 500 and the outside world across the security for certain programs and other information. For example, 
barrier 502. BIU 530 shown in FIG, 9 plus appropriate driver ROM 532 may store "kernel" programs such as SPU control 
software may comprise the "appliance link" 510 shown in firmware 508 and, if desired, encryption key information 
FIG. 6. Bus interface unit 530 may be modelled after a 45 and certain fundamental "load modules." The "kernel" 
US ART or PCI bus interface in the preferred embodiment. programs, load module information, and encryption key 
In this example, BIU 530 connects SPU 500 to electronic information enable the control of certain basic functions of 
appliance system bus 653 shown in FIG. 8. BIU 530 is the SPU 500. Those components that are at least in part 
designed to prevent unauthorized access to internal compo- dependent on device configuration (e.g., POST, memory 
nents within SPU 500 and their contents. It does this by only 50 allocation, and a dispatcher) may be loaded in ROM 532 
allowing signals associated with an SPU 500 to be processed along with additional load modules that have been deter- 
by control programs running on microprocessor 520 and not mined to be required for specific installations or applica- 
supporting direct access to the internal elements of an SPU lions. 

500. In the preferred embodiment, ROM 532 may comprise a 

Memory Management Unit 540 55 combination of a masked ROM 532a and an EEPROM 

Memory Management Unit (MMU) 540, if present, pro- and/or equivalent "flash" memory 5326. EEPROM or flash 

vides hardware support for memory management and virtual memory 5326 is used to store items that need to be updated 

memory management functions. It may also provide height- and/or initialized, such as for example, certain encryption 

ened security by enforcing hardware compartmentalization keys. An additional benefit of providing EEPROM and/or 

of the secure execution space (e.g., to prevent a less trusted 60 flash memory 5326 is the ability to optimize any load 

task from modifying a more trusted task). More details are modules and library functions persistently stored within 

provided below in connection with a discussion of the SPU 500 based on typical usage at a specific site. Although 

architecture of a Secure Processing Environment ("SPE") these items could also be stored in NVRAM 5346, 

503 supported by SPU 500. EEPROM and/or flash memory 5326 may be more cost 

MMU 540 may also provide hardware-level support func- 65 effective, 

tions related to memory management such as, for example, Masked ROM 532a may cost less than flash and/or 

address mapping. EEPROM 5326, and can be used to store permanent portions 
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of SPU software/firmware. Such permanent portions may 
include, for example, code that interfaces to hardware ele- 
ments such as the RTC 528, encryption/decryption engine 
522, interrupt handlers, key generators, etc. Some of the 
operating system, library calls, libraries, and many of the 
core services provided by SPU 500 may also be in masked 
ROM 532a. In addition, some of the more commonly used 
executables are also good candidates for inclusion in masked 
ROM 532a. Items that need to be updated or that need to 
disappear when power is removed from SPU 500 should not 
be stored in masked ROM 532a. 

Under some circumstances, RAM 534a and/or NVRAM 
5346 (NVRAM 5346 may, for example, be constantly 
powered conventional RAM) may perform at least part of 
the role of ROM 532. 

SPU Internal RAM 

SPU 500 general purpose RAM 534 provides, among 
other things, secure execution space for secure processes. In 
the preferred embodiment, RAM 534 is comprised of dif- 
ferent types of RAM such as a combination of high-speed 
RAM 534a and an NVRAM ("non-volatile RAM") 5346. 
RAM 534a may be volatile, while NVRAM 5346 is pref- 
erably battery backed or otherwise arranged so as to be 
non-volatile (i.e., it does not lose its contents when power is 
turned off). 

High-speed RAM 534a stores active code to be executed 
and associated data structures. 

NVRAM 5346 preferably contains certain keys and sum- 
mary values that are preloaded as part of an initialization 
process in which SPU 500 communicates with a VDE 
administrator, and may also store changeable or changing 
information associated with the operation of SPU 500. For 
security reasons, certain highly sensitive information (e.g., 
certain load modules and certain encryption key related 
information such as internally generated private keys) needs 
to be loaded into or generated internally by SPU 500 from 
time to time but, once loaded or generated internally, should 
never leave the SPU. In this preferred embodiment, the SPU 
500 non-volatile random access memory (NVRAM) 5346 
may be used for securely storing such highly sensitive 
information. NVRAM 5346 is also used by SPU 500 to store 
data that may change frequently but which preferably should 
not be lost in a power down or power fail mode. 

NVRAM 5346 is preferably a flash memory array, but 
may in addition or alternatively be electrically erasable 
programmable read only memory (EEPROM), static RAM 
(SRAM), bubble memory, three dimensional holographic or 
other electro -optical memory, or the like, or any other 
writable (e.g., randomly accessible) non- volatile memory of 
sufficient speed and cost-effectiveness. 

SPU External Memory 

The SPU 500 can store certain information on memory 
devices external to the SPU. If available, electronic appli- 
ance 600 memory can also be used to support any device 
external portions of SPU 500 software. Certain advantages 
may be gained by allowing the SPU 500 to use external 
memory. As one example, memory internal to SPU 500 may 
be reduced in size by using non-volatile read/write memory 
in the host electronic appliance 600 such as a non-volatile 
portion of RAM 656 and/or ROM 658. 

Such external memory may be used to store SPU 
programs, data and/or other information. For example, a 
VDE control program may be, at least in part, loaded into the 
memory and communicated to and decrypted within SPU 
500 prior to execution. Such control programs may be 
re-encrypted and communicated back to external memory 
where they may be stored for later execution by SPU 500. 
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"Kernel" programs and/or some or all of the non-kernel 
"load modules" may be stored by SPU 500 in memory 
external to it. Since a secure database 610 may be relatively 
large, SPU 500 can store some or all of secure database 610 
5 in external memory and call portions into the SPU 500 as 
needed. 

As mentioned above, memory external to SPU 500 may 
not be secure. Therefore, when security is required, SPU 500 
must encrypt secure information before writing it to external 

1Q memory, and decrypt secure information read from external 
memory before using it. Inasmuch as the encryption layer 
relies on secure processes and information (e.g., encryption 
algorithms and keys) present within SPU 500, the encryp- 
tion layer effectively "extends" the SPU security barrier 502 
to protect information the SPU 500 stores in memory 

15 external to it. 

SPU 500 can use a wide variety of different types of 
external memory. For example, external memory may com- 
prise electronic appliance secondary storage 652 such as a 
disk; external EEPROM or flash memory 658; and/or exter- 

20 nal RAM 656. External RAM 656 may comprise an external 
nonvolatile (e.g. constantly powered) RAM and/or cache 
RAM. 

Using external RAM local to SPU 500 can significantly 
improve access times to information stored externally to an 
25 SPU. For example, external RAM may be used: 

to buffer memory image pages and data structures prior to 
their storage in flash memory or on an external hard 
disk (assuming transfer to flash or hard disk can occur 
3Q in significant power or system failure cases); 

provide encryption and decryption buffers for data being 

released from VDE objects 300. 
to cache "swap blocks" and VDE data structures currently 
in use as an aspect of providing a secure virtual 
35 memory environment for SPU 500. 

to cache other information in order to, for example, 
reduce frequency of access by an SPU to secondary 
storage 652 and/or for other reasons. 
Dual ported external RAM can be particularly effective in 
40 improving SPU 500 performance, since it can decrease the 
data movement overhead of the SPU bus interface unit 530 
and SPU microprocessor 520. 

Using external flash memory local to SPU 500 can be 
used to significantly improve access times to virtually all 
45 data structures. Since most available flash storage devices 
have limited write lifetimes, flash storage needs to take into 
account the number of writes that will occur during the 
lifetime of the flash memory. Hence, flash storage of fre- 
quently written temporary items is not recommended. If 
50 external RAM is non-volatile, then transfer to flash (or hard 
disk) may not be necessary. 

External memory used by SPU 500 may include two 
categories: 

external memory dedicated to SPU 500, and 
55 memory shared with electronic appliance 600. 

For some VDE implementations, sharing memory (e.g., 
electronic appliance RAM 656, ROM 658 and/or secondary 
storage 652) with CPU 654 or other elements of an elec- 
tronic appliance 600 may be the most cost effective way to 
60 store VDE secure database management files 610 and infor- 
mation that needs to be stored external to SPU 500. A host 
system hard disk secondary memory 652 used for general 
purpose file storage can, for example, also be used to store 
VDE management files 610. SPU 500 may be given exclu- 
65 sive access to the external memory (e.g., over a local bus 
high speed connection provided by BIU 530). Both dedi- 
cated and shared external memory may be provided. 
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SPU Integrated Within CPU 

As discussed above, it may be desirable to integrate CPU 
654 and SPU 500 into the same integrated circuit and/or 
device. SPU 500 shown in FIG. 9 includes a microprocessor 
520 that may be similar or identical to a standard micro- 5 
processor available off-the-shelf from a variety of manufac- 
turers. Similarly, the SPU DMA controller 526 and certain 
other microprocessor support circuitry may be standard 
implementations available in off-the-shelf microprocessor 
and/or microcomputer chips. Since many of the general 10 
control and processing requirements provided by SPU 500 
in the preferred embodiment can be satisfied using certain 
generic CPU and/or microcontroller components, it may be 
desirable to integrate SPU VDE functionality into a standard 
generic CPU or microcontroller chip. Such an integrated 15 
solution can result in a very cost-effective "dual mode" 
component that is capable of performing all of the generic 
processing of a standard CPU as well as the secure process- 
ing of an SPU. Many of the control logic functions per- 
formed by the preferred embodiment SPU can be performed 2 o 
by generic CPU and/or micro-controller logic so that at least 
a portion of the control logic does not have to be duplicated. 
Additional cost savings (e.g., in terms of reducing manu- 
facturing costs, inventory costs and printed circuit board real 
estate requirements) may also be obtained by not requiring 25 
an additional, separate physical SPU 500 device or package. 
FIG. 9A shows one example architecture of a combination 
CPU/SPU 2650. CPU/SPU 2650 may include a standard 
microprocessor or microcontroller 2652, a standard bus 
interface unit (BIU) 2656, and a standard (optional) DMA 30 
controller 2654, as well as various other standard I/O 
controllers, computation circuitry, etc. as may be found in a 
typical off-the-shelf microprocessor/microcontroller. Real 
time clock 528 may be added to the standard architecture to 
give the CPU/SPU 2650 access to the real time clock 35 
functions as discussed above in connection with FIG. 9. 
Real-time clock 528 must be protected from tampering in 
order to be secure. Such protections may include internal or 
external backup power, an indication that its power (and thus 
its operation) has been interrupted, and/or an indication that 40 
the external clock signal(s) from which it derives its timing 
have been interfered with (e.g., sped up, slowed down). 
Similarly, an encrypt/decrypt engine 522, pattern matching 
engine 524, compression/decompression engine 546 and/or 
arithmetic accelerator 544 may be added if desired to 45 
provide greater efficiencies, or the functions performed by 
these components could be provided instead by software 
executing on microprocessor 2652. An optional memory 
management unit 540 may also be provided if desired. A true 
random number generator 542 may be provided also if 50 
desired. Connections shown between mode interface switch 
2658 and other components can carry both data and control 
information, specifically control information that determines 
what security-relevant aspects of the other components are 
available for access and/or manipulation. 55 

In addition, secure ROM 532 and/or secure RAM 534 
may be provided within CPU/SPU 2650 along with a "mode 
interface switch" 2658a, 26586. Mode interface switch 2658 
selectively provides microprocessor 2652 with access to 
secure memory 532, 534 and other secure components 6Q 
(blocks 522, 546, 524, 542, 544, 528) depending upon the 
"mode" CPU/SPU 2650 is operating in, CPU/SPU 2650 in 
this example may operate in two different modes: 

an "SPU" mode, or 

a "normar mode. 65 
In the "normal" mode, CPU/SPU 2650 operates substan- 
tially identically to a standard off-the-shelf CPU while also 
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protecting the security of the content, state, and operations 
of security-relevant components included in CPU/SPU 
2650. Such security-relevant components may include the 
secure memories 532, 534; the encrypt/decrypt engine 522, 
the optional pattern-matching engine 524, random number 
generator 542, arithmetic accelerator 544, the SPU-not- 
initialized flag 2671, the secure mode interface switch 2658, 
the real-time clock 528, the DMA controller 2654, the MMU 
540, compress/decompress block 546, and/or any other 
components that may affect security of the operation of the 
CPU/SPU in "SPU" mode. 

In this example, CPU/SPU 2650 operating in the "nor- 
maTmode controls mode interface switch 2658 to effec- 
tively "disconnect" (i.e., block unsecure access to) the 
security-relevant components, or to the security-relevant 
aspects of the operations of such components as have a 
function for both "normal" and "SPU" mode. In the "nor- 
mal" mode, for example, microprocessor 2652 could access 
information from standard registers or other internal RAM 
and/or ROM (not shown), execute instructions in a "normal" 
way, and perform any other tasks as are provided within a 
standard CPU — but could not access or compromise the 
contents of secure memory 532, 534 or access blocks 522, 
524, 542, 544, 546. In this example "normal" mode, mode 
interface switch 2658 would effectively prevent any access 
(e.g., both read and write access) to secure memory 532, 534 
so as to prevent the information stored within that secure 
memory from being compromised. 

When CPU/SPU 2650 operates in the "SPU" mode, mode 
interface switch 2658 allows microprocessor 2652 to access 
secure memory 532, 534, and to control security-relevant 
aspects of other components in the CPU/SPU. The "SPU" 
mode in this example requires all instructions executed by 
microprocessor 2652 to be fetched from secure memory 
532, 534 — preventing execution based on "mixed" secure 
and non-secure instructions. In the "SPU" mode, mode 
interface switch 2658 may, in one example embodiment, 
disconnect or otherwise block external accesses carried over 
bus 652 from outside CPU/SPU 2650 (e.g., DMA accesses, 
cache coherency control accesses) to ensure that the micro- 
processor 2652 is controlled entirely by instructions carried 
within or derived from the secure memory 532, 534. Mode 
interface switch 2658 may also disconnect or otherwise 
block access by microprocessor 2652 to some external 
memory and/or other functions carried over bus 652. Mode 
interface switch 2658 in this example prevents other CPU 
operations/instructions from exposing the contents of secure 
memory 532, 534. 

In the example shown in FIG. 9A, the mode control of 
mode interface switch 2658 is based on a "mode" control 
signal provided by microprocessor 2652. In this example, 
microprocessor 2652 may be slightly modified so it can 
execute two "new" instructions: 

"enable 'SPU' mode" instruction, and 

"disable 'SPU* mode" instruction. 

When microprocessor 2652 executes the "enable 'SPU* 
mode" instruction, it sends an appropriate "mode" control 
signal to mode interface switch 2658 to "switch" the inter- 
face switch into the "SPU" mode of operation. When 
microprocessor 2652 executes the "disable 'SPU' mode" 
instruction, it sends an appropriate "mode" control signal to 
mode interface switch 2658 to disable the "SPU" mode of 
operation. 

When CPU/SPU 2650 begins operating in the "SPU" 
mode (based on microprocessor 2652 executing the "enable 
"SPU" mode" instruction), mode interface switch 2658 
forces microprocessor 2652 to begin fetching instructions 
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from secure memory 532, 534 (e.g., beginning at some fixed 
address) in one example. When CPU/SPU 2650 begins 
operating in this example "SPU" mode, mode interface 
switch 2658 may force microprocessor 2652 to load its 
registers from some fixed address in secure memory 532, 
534 and may begin execution based on such register content. 
Once operating in the "SPU" mode, microprocessor 2652 
may provide encryption/decryption and other control capa- 
bilities based upon the code and other content of secure 
memory 532, 534 needed to provide the VDE functionality 
of SPU 500 described above. For example, microprocessor 
2652 operating under control of information within secure 
memory 532, 534 may read encrypted information from bus 
652 via bus interface unit 2656, write decrypted information 
to the bus interface unit, and meter and limit decryption of 
such information based on values stored in the secure 
memory. 

At the end of secure processing, execution by micropro- 
cessor 2652 of the "disable SPU mode" instruction may 
cause the contents of all registers and other temporary 
storage locations used by microprocessor 2652 that are not 
within secure memory 532, 534 to be destroyed or copied 
into secure memory 532, 534 before "opening" mode inter- 
face switch 2658. Once mode interface switch 2658 is 
"open," the microprocessor 2652 no longer has access to 
secure memory 532, 534 or the information it contained, or 
to control or modify the state of any other security-relevant 
components or functions contained within CPU/SPU 2650 
to which access is controlled by mode interface switch 2658. 

Whenever CPU/SPU 2650 enters or leaves the "SPU" 
mode, the transition is performed in such a way that no 
information contained in the secure memory 532, 534 or 
derived from it (e.g., stored in registers or a cache memory 
associated with microprocessor 2652) while in the "SPU" 
mode can be exposed by microprocessor 2652 operations 
that occur in the "normal" mode. This may be accomplished 
either by hardware mechanisms that protect against such 
exposure, software instructions executed in "SPU" mode 
that clear, reinitialize, and otherwise reset during such 
transitions, or a combination of both. 

In some example implementations, interrupts may be 
enabled while CPU/SPU 2650 is operating in the "SPU" 
mode similarly interrupts and returns from interrupts while 
in the "SPU" mode may allow transitions from "SPU" mode 
to "normal" mode and back to "SPU" mode without expos- 
ing the content of secure memory 532, 534 or the content of 
registers or other memory associated with microprocessor 
2652 that may contain information derived from secure 
mode operation. 

In some example implementations, there may be CPU/ 
SPU activities such as DMA transfers between external 
memory and/or devices and secure memory 532, 534 that are 
initiated by microprocessor 2652 but involve autonomous 
activity by DMA controller 2654 and, optionally, encrypt/ 
decrypt engine 522 and/or compress/decompress engine 
546. In such implementations, mode interface switch 2658 
and its associated control signals may be configured to 
permit such pending activities (e.g. DMA transfers) to 
continue to completion even after CPU/SPU 2650 leaves 
"SPU" mode, provided that upon completion, all required 
clearing, reinitialization, and/or reset activities occur, and 
provided that no access or interference is permitted with the 
pending activities except when CPU/SPU 2650 is operating 
in "SPU" mode. 

In an additional example embodiment, encryption/ 
decryption logic may be connected between microprocessor 
2652 and secure memory 532, 354. This additional 
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encryption/decryption logic may be connected "in parallel" 
to mode interface switch 2658. Tne additional encryption/ 
decryption logic may allow certain accesses by micropro- 
cessor 2652 to the secure memory 532, 534 when CPU/SPU 

s 2650 is operating in the "normal" mode. In this alternate 
embodiment, reads from secure memory 532, 534 when 
CPU/SPU 2650 is operating in the "normal" mode auto- 
matically result in the read information being encrypted 
before it is delivered to microprocessor 2652 (and similarly, 

10 and writes to the secure memory may result in the written 
information being decrypted before it is deposited into the 
secure memory). This alternative embodiment may permit 
access to secure memory 532, 534 (which may in this 
example store the information in "clear" form) by micro- 

15 processor 2652 when CPU/SPU 2650 is operating in the 
"non-secure normal" mode, but only reveals the secure 
memory contents to microprocessor 2652 in unencrypted 
form when the CPU/SPU is operating in the "SPU" mode. 
Such access may also be protected by cryptographic authen- 

20 tication techniques (e.g., message authentication codes) to 
prevent modification or replay attacks that modify encrypted 
data stored in secure memory 532, 534. Such protection may 
be performed utilizing either or both of software and/or 
hardware cryptographic techniques. 

25 All of the components shown in FIG. 9 A may be disposed 
within a single integrated circuit package. Alternatively, 
mode interface switch 2658 and secure memory 532, 534, 
and other security-relevant components might be placed 
within an integrated circuit chip package and/or other pack- 

30 age separate from the rest of CPU/SPU 2650. In this 
two-package version, a private bus could be used to connect 
microprocessor 2652 to the mode interface switch 2658 and 
associated secure memory 532, 534. To maintain security in 
such multi-package versions, it may be necessary to enclose 

35 all the packages and their interconnections in an external 
physical tamper-resistant barrier. 
Initialization of Integrated CPU/SPU 
Instructions and/or data may need to be loaded into 
CPU/SPU 2650 before it can operate effectively as an SPU 

40 500. This may occur during the manufacture of CPU/SPU 
2650 or subsequently at a CPU/SPU initialization facility. 
Security of such initialization may depend on physical 
control of access to the CPU/SPU component(s), on cryp- 
tographic means, or on some combination of both. Secure 

45 initialization may be performed in plural steps under the 
control of different parties, such that an initialization step to 
be performed by party B is preconditioned on successful 
performance of a step by party A. Different initialization 
steps may be protected using different security techniques 

50 (e.g. physical access, cryptography). 

In this example, switch 2658 may expose an external 
control signal 2670 that requests operation in "SPU" mode 
rather than "normal" mode after a power-on reset. This 
signal would be combined (e.g., by a logical AND 2672) 

55 with a non-volatile storage element 2671 internal to CPU/ 
SPU 2650. If both of these signals are asserted, AND gate 
2672 would cause CPU/SPU 2650 to begin operating in SPU 
mode, either executing existing instructions from an address 
in SPU memory 532, executing instructions from main 

60 memory 2665 or otherwise external to the CPU/SPU. The 
instructions thus executed would permit arbitrary initializa- 
tion and other functions to be performed in "SPU" mode 
without necessarily requiring any instructions to be previ- 
ously resident in the SPU memory 532. 

65 Once initialized, the SPU would, under control of its 
initialization program, indicate to switch 2658 that the flag 
2671 is to be cleared. Clearing flag 2671 would permanently 
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disable this initialization capability because no mechanism 
would be provided to set flag 2671 back to its initial value. 
If flag 2671 is clear, or control signal 2670 is not asserted, 
CPU/SPU 2650 would behave precisely as does micropro- 
cessor 2652 with respect to power-on reset and other exter- 5 
nal conditions. Under such conditions, only execution of the 
"enable SPU mode" instruction or otherwise requesting SPU 
mode under program control would cause "SPU" mode to be 
entered. 

Additionally, a mechanism could be provided to permit 10 
microprocessor 2652 and/or control signal 2672 to reinitial- 
ize the flag 2671. Such reinitialization would be performed 
in a manner that cleared secure memory 532, 534 of any 
security-relevant information and reinitialized the state of all 
security-relevant components. This reinitialization mecha- 15 
nism would permit CPU/SPU 2650 to be initialized several 
times, facilitating testing and/or re-use for different 
applications, while protecting all security-relevant aspects of 
its operation. 

In the preferred embodiment, CPU/SPU 2650 would, 20 
when SPU mode has not yet been established, begin oper- 
ating in SPU mode by fetching instructions from secure 
non-volatile memory 532, thereby ensuring a consistent 
initialization sequence and preventing SPU dependence on 
any information held outside CPU/SPU 2650. This approach 25 
permits secret initialization information (e.g., keys for vali- 
dating digital signatures on additional information to be 
loaded into secure memory 532, 534) to be held internally to 
CPU/SPU 2650 so that it is never exposed to outside access. 
Such information could even be supplied by a hardware 30 
"mask" used in the semiconductor fabrication process. 

CPU/SPU Integrated With Unmodified Microprocessor 

FIG. 9B shows an additional example embodiment, in 
which a completely standard microprocessor 2652 inte- 
grated circuit chip could be transformed into a CPU/SPU 35 
2650 by adding an SPU chip 2660 that mediates access to 
external I/O devices and memory. In such an embodiment, 
the microprocessor 2652 would be connected to the SPU 
chip 2660 by a private memory bus 2661, and all three such 
components would be contained within hardware tamper- 40 
resistant barrier 502. 

In this embodiment, SPU chip 2660 may have the same 
secure components as in FIG. 9, i.e., it may have a ROM/ 
EEPROM 532, a RAM 532, an RTC 528, an (optional) 
encryption/decryption engine 522, an (optional) random 45 
number generator (RNG) 542, an (optional) arithmetic 
accelerator 544, and a (optional) compression/ 
decompression engine 546, and a (optional) pattern match- 
ing circuit 524. Microprocessor 520 is omitted from SPU 
chip 2660 since the standard microprocessor 2650 performs 50 
the processing functions instead. In addition, SPU chip 2660 
may include a flag 2671 and AND gate logic 2672 for the 
initialization purposes discussed above. 

In addition, SPU chip 2660 includes an enhanced switch 

2663 that provides the same overall (bus enhanced) func- 55 
tionality performed by the switch 2658 in the FIG. 9 A 
embodiment. 

Enhanced switch 2663 would perform the functions of a 
bus repeater, mediator and interpreter. For example, 
enhanced switch 2663 may act as a bus repeater that enables 60 
microprocessor 2652 's memory accesses made over internal 
memory bus 2661 to be reflected to external memory bus 

2664 and performed on main memory 2665. Enhanced 
switch 2663 may also act as a bus repeater similarly for 
internal I/O bus 2662 to external I/O bus 2665 in the event 65 
that microprocessor 2652 performs I/O operations distinctly 
from memory operations. Enhanced switch 2663 may also 
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perform the function of a mediator for microprocessor 
control functions 2666 (e.g., non-maskable interrupt, reset) 
with respect to externally requested control functions 2667. 
Enhanced switch 2663 may also provide mediation for 
access to SPU-protected resources such as ROM 532, RAM 
534, encrypt/decrypt engine 522 (if present), random num- 
ber generator 542 (if present), arithmetic accelerator 544 (if 
present), pattern matching engine 524 (if present), and 
real-time clock 528 (if present). Enhanced switch 2663 may 
also act as an interpreter of control signals received from 
microprocessor 2652 indicating entry to, exit from, and 
control of SPU mode. 

Switch 2663 in this example recognizes a specific indi- 
cation (e.g., an instruction fetch access to a designated 
address in the secure memory 532) as the equivalent to the 
"enable 'SPU' mode" instruction. Upon recognizing such an 
indication, it may isolate the CPU/SPU 2650 from external 
buses and interfaces 2664, 2665, and 2667 such that any 
external activity, such as DMA cycles, would be "held" until 
the switch 2663 permits access again. After this, switch 2663 
permits a single access to a specific location in secure 
memory 532 to complete. 

The single instruction fetched from the designated loca- 
tion performs a control operation (a cache flush, for 
example), that can only be performed in microprocessor 
2652's most privileged operating mode, and that has an 
effect visible to switch 2663. Switch 2663 awaits the occur- 
rence of this event, and if it does not occur within the 
expected number of cycles, does not enter "SPU" mode. 

Occurrence of the control operation demonstrates that 
microprocessor 2652 is executing in its most privileged 
"normal" mode and therefore can be trusted to execute 
successfully the "enter 'SPU' mode" sequence of instruc- 
tions stored in secure memory 532. If microprocessor 2652 
were not executing in its most privileged mode, there would 
be no assurance that those instructions would execute suc- 
cessfully. Because switch 2663 isolates microprocessor 
2652 from external signals (e.g., interrupts) until "SPU" 
mode is successfully initialized, the entry instructions can be 
guaranteed to complete successfully. 

Following the initial instruction, switch 2663 can enter 
"partial SPU mode," in which a restricted area of ROM 532 
and RAM 534 may be accessible. Subsequent instructions in 
secure memory 532 may then be executed by microproces- 
sor 2652 to place it into a known state such that it can 
perform SPU functions — saving any previous state in the 
restricted area of RAM 534 that is accessible. After the 
known state is established, an instruction may be executed 
to deliver a further indication (e.g., a reference to another 
designated memory location) to switch 2663, which would 
enter "SPU" mode. If this further indication is not received 
within the expected interval, switch 2663 will not enter 
"SPU" mode. Once in "SPU" mode, switch 2663 permits 
access to all of ROM 532, RAM 534, and other devices in 
SPU chip 2660. 

The instructions executed during "partial SPU" mode 
must be carefully selected to ensure that no similar combi- 
nation of instructions and processor state could result in a 
control transfer out of the protected SPU code in ROM 532 
or RAM 534. For example, internal debugging features of 
microprocessor 2652 must be disabled to ensure that a 
malicious program could not set up a breakpoint later within 
protected SPU code and receive control. Similarly, all 
address translation must be disabled or reinitialized to 
ensure that previously created MMU data structures would 
not permit SPU memory accesses to be compromised. The 
requirement that the instructions for "partial SPU mode" run 
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in the microprocessor 2652 's most privileged mode is nec- 
essary to ensure that all its processor control functions can 
be effectively disabled. 

The switch 2663 provides additional protection against 
tampering by ensuring that the expected control signals 5 
occur after an appropriate number of clock cycles. Because 
the "partial SPU" initialization sequence is entirely 
deterministic, it is not feasible for malicious software to 
interfere with it and still retain the same timing 
characteristics, even if malicious software is running in 
microprocessor 2652's most privileged mode. 

Once in "SPU" mode, switch 2663 may respond to 
additional indications or signals generated by microproces- 
sor 2652 (e.g., references to specific memory addresses) 
controlling features of SPU mode. These might include 
enabling access to external buses 2664 and 2665 so that 15 
SPU-protected code could reference external memory or 
devices. Any attempts by components outside CPU/SPU 
2650 to perform operations (e.g., accesses to memory, 
interrupts, or other control functions) may be prevented by 
switch 2663 unless they had been explicitly enabled by 20 
instructions executed after "SPU" mode is entered. To leave 
SPU mode and return to normal operation, the instructions 
executing in "SPU" mode may provide a specific indication 
to switch 2663 (e.g., a transfer to a designated memory 
address). This indication may be recognized by switch 2663 25 
as indicating a return to "normal mode," and it may again 
restrict access to ROM 532, RAM 534, and all other devices 
within SPU chip 2660, while re-enabling external buses and 
control fines 2664, 2665, and 2667. The instructions 
executed subsequently may restore the CPU state to that 30 
which was saved on entry to SPU mode, so that micropro- 
cessor 2652 may continue to perform functions in progress 
when the SPU was invoked. 

In an alternate embodiment, the entry into SPU mode may 
be conditioned on an indication recognized by switch 2663, 35 
but the switch may then use a hardware mechanism (e.g., the 
processor's RESET signal) to reinitialize microprocessor 
2562. In such an embodiment, switch 2663 may not imple- 
ment partial SPU mode, but may instead enter SPU mode 
directly and ensure that the address from which instructions 40 
would be fetched by microprocessor 2652 (specific to micro- 
processor 2652's architecture) results in accesses to appro- 
priate locations in the SPU memory 532. This could reduce 
the complexity of the SPU mode entry mechanisms in 
switch 2663, but could incur an additional processing cost 45 
from using a different reinitialization mechanism for micro- 
processor 2652. 

SPU chip 2660 may be customized to operate in conjunc- 
tion with a particular commercial microprocessor. In this 
example, the SPU may be customized to contain at least the 50 
specialized "enter SPU mode" instruction sequences to 
reinitialize the processor's state and, to recognize special 
indications for SPU control operations. SPU chip 2660 may 
also be made electrically compatible with microprocessor 
2652's external bus interfaces. This compatibility would 55 
permit CPU/SPU 2650 to be substituted for microprocessor 
2652 without change either to software or hardware else- 
where in a computer system. 

In other alternate embodiments, the functions described 
above for SPU chip 2600, microprocessor 2652, and internal 60 
buses 2661, 2662, and 2666 could all be combined within a 
single integrated circuit package, and/or on a single silicon 
die. This could reduce packaging complexity and/or sim- 
plify establishment of the hardware tamper-resistant barrier 
502. 65 

The hardware configuration of an example of electronic 
appliance 600 has been described above. The following 
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section describes an example of the software architecture of 
electronic appliance 600 provided by the preferred 
embodiment, including the structure and operation of pre- 
ferred embodiment "Rights Operating System" ("ROS") 
602. 

Rights Operating System 602 

Rights Operating System ("ROS") 602 in the preferred 
embodiment is a compact, secure, event-driven, services- 
based, "component" oriented, distributed multiprocessing 
operating system environment that integrates VDE informa- 
tion security control information, components and protocols 
with traditional operating system concepts. Like traditional 
operating systems, ROS 602 provided by the preferred 
embodiment is a piece of software that manages hardware 
resources of a computer system and extends management 
functions to input and/or output devices, including commu- 
nications devices. Also like traditional operating systems, 
preferred embodiment ROS 602 provides a coherent set of 
basic functions and abstraction layers for hiding the differ- 
ences between, and many of the detailed complexities of, 
particular hardware implementations. In addition to these 
characteristics found in many or most operating systems, 
ROS 602 provides secure VDE transaction management and 
other advantageous features not found in other operating 
systems. The following is a non-exhaustive list of some of 
the advantageous features provided by ROS 602 in the 
preferred embodiment: 

Standardized interface provides coherent set of basic 
functions 

simplifies programming 

the same application can run on many different platforms 
Event driven 

eases functional decomposition 
extendible 

accommodates state transition and/or process oriented 
events 

simplifies task management 

simplifies inter-process communications 

Services based 

allows simplified and transparent scalability 

simplifies multiprocessor support 

hides machine dependencies 

eases network management and support 

Component Based Architecture 

processing based on independently deliverable secure 
components 

component model of processing control allows different 
sequential steps that are reconfigurable based on 
requirements 

components can be added, deleted or modified (subject to 

pe missioning) 
full control information over pre-defined and user-defined 

application events 
events can be individually controlled with independent 

execu tables 
Secure 

secure communications 
secure control functions 
secure virtual memory management 
information control structures protected from exposure 
data elements are validated, correlated and access con- 
trolled 

components are encrypted and validated independently 
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components are tightly correlated to prevent unauthorized 

use of elements 
control structures and secured executables are validated 

prior to use to protect against tampering 
integrates security considerations at the I/O level 
provides on-the-fly decryption of information at release 

time 

enables a secure commercial transaction network 

flexible key management features 

Scalaeble 

highly scalaeble across many different platforms 
supports concurrent processing in a multiprocessor envi- 
ronment 

supports multiple cooperating processors 
any number of host or security processors can be sup- 
ported 

control structures and kernel are easily portable to various 
host platforms and to different processors within a 
target platform without recompilation 

supports remote processing 

Remote Procedure Calls may be used for internal OS 

communications 
Highly Integratable 

can be highly integrated with host platforms as an addi- 
tional operating system layer 

permits non-secure storage of secured components and 
information using an OS layer "on top of' traditional 
OS platforms 

can be seamlessly integrated with a host operating system 
to provide a common usage paradigm for transaction 
management and content access 

integration may take many forms: operating system layers 
for desktops (e.g., DOS, Windows, Macintosh); device 
drivers and operating system interfaces for network 
services (e.g, Unix and Netware); and dedicated com- 
ponent drivers for "low end" set tops are a few of many 
examples 

can be integrated in traditional and real time operating 

systems 
Distributed 

provides distribution of control information and recipro- 
cal control information and mechanisms 

supports conditional execution of controlled processes 
within any VDE node in a distributed, asynchronous 
arrangement 

controlled delegation of rights in a distributed environ- 
ment 

supports chains of handling and control 

management environment for distributed, occasionally 
connected but otherwise asynchronous networked data- 
base 

real time and time independent data management 

supports "agent" processes 

Transparent 

can be seamlessly integrated into existing operating sys- 
tems 

can support applications not specifically written to use it 
Network friendly 

internal OS structures may use RPCs to distribute pro- 
cessing 

subnets may seamlessly operate as a single node or 
independently 
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General Background Regarding Operating Systems 
An "operating system" provides a control mechanism for 
organizing computer system resources that allows program- 
mers to create applications for computer systems more 
s easily. An operating system does this by providing com- 
monly used functions, and by helping to ensure compatibil- 
ity between different computer hardware and architectures 
(which may, for example, be manufactured by different 
vendors). Operating systems also enable computer "periph- 
10 era! device" manufacturers to far more easily supply com- 
patible equipment to computer manufacturers and users. 

Computer systems are usually made up of several differ- 
ent hardware components. These hardware components 
include, for example: 
15 a central processing unit (CPU) for executing instructions; 
an array of main memory cells (e.g., "RAM" or "ROM") 
for storing instructions for execution and data acted 
upon or parameterizing those instructions; and 
one or more secondary storage devices (e.g., hard disk 
20 drive, floppy disk drive, CD-ROM drive, tape reader, 
card reader, or "flash" memory) organized to reflect 
named elements (a "file system") for storing images of 
main memory cells. 
Most computer systems also include input/output devices 
25 such as keyboards, mice, video systems, printers, scanners 
and communications devices. 

To organize the CPU's execution capabilities with avail- 
able RAM, ROM and secondary storage devices, and to 
provide commonly used functions for use by programmers, 
30 a piece of software called an "operating system" is usually 
included with the other components. Typically, this piece of 
software is designed to begin executing after power is 
applied to the computer system and hardware diagnostics are 
completed. Thereafter, all use of the CPU, main memory and 
35 secondary memory devices is normally managed by this 
"operating system" software. Most computer operating sys- 
tems also typically include a mechanism for extending their 
management functions to I/O and other peripheral devices, 
including commonly used functions associated with these 
40 devices. 

By managing the CPU, memory and peripheral devices 
through the operating system, a coherent set of basic func- 
tions and abstraction layers for hiding hardware details 
allows programmers to more easily create sophisticated 

45 applications. In addition, managing the computer's hard- 
ware resources with an operating system allows many 
differences in design and equipment requirements between 
different manufacturers to be hidden. Furthermore, applica- 
tions can be more easily shared with other computer users 

50 who have the same operating system, with significantly less 
work to support different manufacturers' base hardware and 
peripheral devices. 

ROS 602 is an Operating System Providing Significant 
Advantages 

55 ROS 602 is an "operating system/* It manages the 
resources of electronic appliance 600, and provides a com- 
monly used set of functions for programmers writing appli- 
cations 608 for the electronic appliance. ROS 602 in the 
preferred embodiment manages the hardware (e.g., CPU(s), 

60 memory(ies), secure RTC(s), and encrypt/decrypt engines) 
within SPU 500. ROS may also manage the hardware (e.g., 
CPU(s) and memory(ies)) within one or more general pur- 
pose processors within electronic appliance 600. ROS 602 
also manages other electronic appliance hardware resources, 

65 such as peripheral devices attached to an electronic appli- 
ance. For example, referring to FIG. 7, ROS 602 may 
manage keyboard 612, display 614, modem 618, disk drive 
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620, printer 622, scanner 624. ROS 602 may also manage 
secure database 610 and a storage device (e.g., "secondary 
storage" 652) used to store secure database 610. 

ROS 602 supports multiple processors. ROS 602 in the 
preferred embodiment supports any number of local and/or 
remote processors. Supported processors may include at 
least two types: one or more electronic appliance processors 
654, and/or one or more SPUs 500. A host processor CPU 
654 may provide storage, database, and communications 
services. SPU 500 may provide cryptographic and secured 
process execution services. Diverse control and execution 
structures supported by ROS 602 may require that process- 
ing of control information occur within a controllable execu- 
tion space — this controllable execution space may be pro- 
vided by SPU 500. Additional host and/or SPU processors 
may increase efficiencies and/or capabilities. ROS 602 may 
access, coordinate and/or manage further processors remote 
to an electronic appliance 600 (e.g., via network or other 
communications link) to provide additional processor 
resources and/or capabilities. 

ROS 602 is services based. The ROS services provided 
using a host processor 654 and/or a secure processor (SPU 
500) are linked in the preferred embodiment using a 
"Remote Procedure Call" ("RPC") internal processing 
request structure. Cooperating processors may request inter- 
process services using a RPC mechanism, which is mini- 
mally time dependent and can be distributed over cooper- 
ating processors on a network of hosts. The multi-processor 
architecture provided by ROS 602 is easily extensible to 
support any number of host or security processors. This 
extensibility supports high levels of scalability. Services also 
allow functions to be implemented differently on different 
equipment. For example, a small appliance that typically has 
low levels of usage by one user may implement a database 
service using very different techniques than a very large 
appliance with high levels of usage by many users. This is 
another aspect of scalability. 

ROS 602 provides a distributed processing environment. 
For example, it permits information and control structures to 
automatically, securely pass between sites as required to 
fulfill a user's requests. Communications between VDE 
nodes under the distributed processing features of ROS 602 
may include interprocess service requests as discussed 
above. ROS 602 supports conditional and/or state dependent 
execution of controlled processors within any VDE node. 
The location that the process executes and the control 
structures used may be locally resident, remotely accessible, 
or carried along by the process to support execution on a 
remote system. 

ROS 602 provides distribution of control information, 
including for example the distribution of control structures 
required to permit "agents" to operate in remote environ- 
ments. Thus, ROS 602 provides facilities for passing execu- 
tion and/or information control as part of emerging require- 
ments for "agent" processes. 

If desired, ROS 602 may independently distribute control 
information over very low bandwidth connections that may 
or may not be "real time" connections. ROS 602 provided by 
the preferred embodiment is "network friendly," and can be 
implemented with any level of networking protocol. Some 
examples include e-mail and direct connection at approxi- 
mately "Layer 5" of the ISO model. 

The ROS 602 distribution process (and the associated 
auditing of distributed information) is a controlled event that 
itself uses such control structures. This "reflective" distrib- 
uted processing mechanism permits ROS 602 to securely 
distribute rights and permissions in a controlled manner, and 
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effectively restrict the characteristics of use of information 
content. The controlled delegation of rights in a distributed 
environment and the secure processing techniques used by 
ROS 602 to support this approach provide significant advan- 
s tages. 

Certain control mechanisms within ROS 602 are "recip- 
rocal." Reciprocal control mechanisms place one or more 
control components at one or more locations that interact 
with one or more components at the same or other locations 

10 in a controlled way. For example, a usage control associated 
with object content at a user's location may have a reciprocal 
control at a distributor's location that governs distribution of 
the usage control, auditing of the usage control, and logic to 
process user requests associated with the usage control. A 

15 usage control at a user's location (in addition to controlling 
one or more aspects of usage) may prepare audits for a 
distributor and format requests associated with the usage 
control for processing by a distributor. Processes at either 
end of a reciprocal control may be further controlled by 

20 other processes (e.g., a distributor may be limited by a 
budget for the number of usage control mechanisms they 
may produce). Reciprocal control mechanisms may extend 
over many sites and many levels (e.g., a creator to a 
distributor to a user) and may take any relationship into 

25 account (e.g., creator/distributor, distributor/user, user/user, 
user/creator, user/creator/distributor, etc.) Reciprocal con- 
trol mechanisms have many uses in VDE 100 in representing 
relationships and agreements in a distributed environment, 
ROS 602 is scalable. Many portions of ROS 602 control 

30 structures and kernel(s) are easily portable to various host 
platforms without recompilation. Any control structure may 
be distributed (or redistributed) if a granting authority per- 
mits this type of activity. The executable references within 
ROS 602 are portable within a target platform. Different 

35 instances of ROS 602 may execute the references using 
different resources. For example, one instance of ROS 602 
may perform a task using an SPU 500, while another 
instance of ROS 602 might perform the same task using a 
host processing environment running in protected memory 

40 that is emulating an SPU in software. ROS 602 control 
informationis similarly portable; in many cases the event 
processing structures may be passed between machines and 
host platforms as easily as between cooperative processors 
in a single computer. Appliances with different levels of 

45 usage and/or resources available for ROS 602 functions may 
implement those functions in very different ways. Some 
services may be omitted entirely if insufficient resources 
exist. As described elsewhere, ROS 602 "knows" what 
services are available, and how to proceed based on any 

50 given event. Not all events may be processable if resources 
are missing or inadequate. 

ROS 602 is component based. Much of the functionality 
provided by ROS 602 in the preferred embodiment may be 
based on "components" that can be securely, independently 

55 deliverable, replaceable and capable of being modified (e.g., 
under appropriately secure conditions and authorizations). 
Moreover, the "components" may themselves be made of 
independently deliverable elements. ROS 602 may assemble 
these elements together (using a construct provided by the 

60 preferred embodiment called a "channel") at execution time. 
For example, a "load module" for execution by SPU 500 
may reference one or more "method cores," method param- 
eters and other associated data structures that ROS 602 may 
collect and assemble together to perform a task such as 

65 billing or metering. Different users may have different 
combinations of elements, and some of the elements may be 
customizable by users with appropriate authorization. This 
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increases flexibility, allows elements to be reused, and has 
other advantages. 

ROS 602 is highly secure. ROS 602 provides mechanisms 
to protect information control structures from exposure by 
end users and conduit hosts. ROS 602 can protect 
information, VDE control structures and control executables 
using strong encryption and validation mechanisms. These 
encryption and validation mechanisms are designed to make 
them nighty resistant to undetected tampering. ROS 602 
encrypts information stored on secondary storage device(s) 
652 to inhibit tampering. ROS 602 also separately encrypts 
and validates its various components. ROS 602 correlates 
control and data structure components to prevent unautho- 
rized use of elements. These features permit ROS 602 to 
independently distribute elements, and also allows integra- 
tion of VDE functions 604 with non-secure "other" OS 
functions 606. 

ROS 602 provided by the preferred embodiment extends 
conventional capabilities such as, for example, Access Con- 
trol List (ACL) structures, to user and process defined 
events, including state transitions. ROS 602 may provide 
full control information over pre-defined and user-defined 
application events. These control mechanisms include "go/ 
no-go" permissions, and also include optional event-specific 
executables that permit complete flexibility in the processing 
and/or controlling of events. This structure permits events to 
be individually controlled so that, for example, metering and 
budgeting may be provided using independent executables. 
For example, ROS 602 extends ACL structures to control 
arbitrary granularity of information. Traditional operating 
systems provide static "go-no go" control mechanisms at a 
file or resource level; ROS 602 extends the control concept 
in a general way from the largest to the smallest sub-element 
using a flexible control structure. ROS 602 can, for example, 
control the printing of a single paragraph out of a document 
file. 

ROS 602 provided by the preferred embodiment permits 
secure modification and update of control information gov- 
erning each component. The control information may be 
provided in a template format such as method options to an 
end-user. An end-user may then customize the actual control 
information used within guidelines provided by a distributor 
or content creator.* Modification and update of existing 
control structures is preferably also a controllable event 
subject to auditing and control information. 

ROS 602 provided by the preferred embodiment validates 
control structures and secured executables prior to use. This 
validation provides assurance that control structures and 
executables have not been tampered with by end-users. The 
validation also permits ROS 602 to securely implement 
components that include fragments of files and other oper- 
ating system structures. ROS 602 provided by the preferred 
embodiment integrates security considerations at the oper- 
ating system I/O level (which is below the access level), and 
provides "on-the-fly" decryption of information at release 
time. These features permit non-secure storage of ROS 602 
secured components and information using an OS layer "on 
top of traditional operating system platforms. 

ROS 602 is highly integratable with host platforms as an 
additional operating system layer. Thus, ROS 602 may be 
created by "adding on" to existing operating systems. This 
involves hooking VDE "add ons" to the host operating 
system at the device driver and network interface levels. 
Alternatively, ROS 602 may comprise a wholly new oper- 
ating system that integrates both VDE functions and other 
operating system functions. 

Indeed, there are at least three general approaches to 
integrating VDE functions into a new operating system, 
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potentially based on an existing operating system, to create 
a Rights Operating System 602 including: 

(1) Redesign the operating system based on VDE trans- 
action management requirements; 
5 (2) Compile VDE API functions into an existing operating 
systems; and 

(3) Integrate a VDE Interpreter into an existing operating 
system. 

The first approach could be most effectively applied when 

10 a new operating system is being designed, or if a significant 
upgrade to an existing operating system is planned. The 
transaction management and security requirements provided 
by the VDE functions could be added to the design require- 
ments list for the design of a new operating system that 

15 provides, in an optimally efficient manner, an integration of 
"traditional" operating system capabilities and VDE capa- 
bilities. For example, the engineers responsible for the 
design of the new version or instance of an operating system 
would include the requirements of VDE metering/ 

20 transaction management in addition to other requirements (if 
any) that they use to form their design approach, 
specifications, and actual implementations. This approach 
could lead to a "seamless" integration of VDE functions and 
capabilities by threading metering/transaction management 

25 functionality throughout the system design and implemen- 
tation. 

The second approach would involve taking an existing set 
of API (Application Programmer Interface) functions, and 
incorporating references in the operating system code to 

30 VDE function calls. This is similar to the way that the 
current Windows operating system is integrated with DOS, 
wherein DOS serves as both the launch point and as a 
significant portion of the kernel underpinning of the Win- 
dows operating system. This approach would be also pro- 

35 vide a high degree of "seamless" integration (although not 
quite as "seamless" as the first approach). The benefits of 
this approach include the possibility that the incorporation of 
metering/transaction management functionality into the new 
version or instance of an operating system may be accom- 

40 plished with lower cost (by making use of the existing code 
embodied in an API, and also using the design implications 
of the API functional approach to influence the design of the 
elements into which the metering/transaction management 
functionality is incorporated). 

45 The third approach is distinct from the first two in that it 
does not incorporate VDE functionality associated with 
metering/transaction management and data security directly 
into the operating system code, but instead adds a new 
generalized capability to the operating system for executing 

50 metering/transaction management functionality. In this case, 
an interpreter including metering/transaction management 
functions would be integrated with other operating system 
code in a "stand alone" mode. This interpreter might take 
scripts or other inputs to determine what metering/ 

55 transaction management functions should be performed, and 
in what order and under which circumstances or conditions 
they should be performed. 

Instead of (or in addition to) integrating VDE functions 
into/with an electronic appliance operating system, it would 

60 be possible to provide certain VDE functionality available as 
an application running on a conventional operating system. 
ROS Software Architecture 

FIG. 10 is a block diagram of one example of a software 
structure/architecture for Rights Operating System ("ROS") 
65 602 provided by the preferred embodiment. In this example, 
ROS 602 includes an operating system ("OS") "core" 679, 
a user Application Program Interface ("API") 682, a "redi- 
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rector" 684, an "intercept" 692, a User Notification/ 
Exception Interface 686, and a file system 687. ROS 602 in 
this example also includes one or more Host Event Process- 
ing Environments ("HPEs") 655 and/or one or more Secure 
Event Processing Environments ("SPEs") 503 (these envi- 
ronments may be generically referred to as "Protected 
Processing Environments" 650). 

HPE(s) 655 and SPE(s) 503 are self-contained computing 
and processing environments that may include their own 
operating system kernel 688 including code and data pro- 
cessing resources. A given electronic appliance 600 may 
include any number of SPE(s) 503 and/or any number of 
HPE(s) 655. HPE(s) 655 and SPE(s) 503 may process 
information in a secure way, and provide secure processing 
support for ROS 602. For example, they may each perform 
secure processing based on one or more VDE component 
assemblies 690, and they may each offer secure processing 
services to OS kernel 680. 

In the preferred embodiment, SPE 503 is a secure pro- 
cessing environment provided at least in part by an SPU 500. 
Thus, SPU 500 provides the hardware tamper-resistant bar- 
rier 503 surrounding SPE 503. SPE 503 provided by the 
preferred embodiment is preferably; 

small and compact 

loadable into resource constrained environments such as 

for example minimally configured SPUs 500 
dynamically updatable 
extensible by authorized users 
integratable into object or procedural environments 
secure. 

In the preferred embodiment, HPE 655 is a secure pro- 
cessing environment supported by a processor other than an 
SPU, such as for example an electronic appliance CPU 654 
general-purpose microprocessor or other processing system 
or device. In the preferred embodiment, HPE 655 may be 
considered to "emulate" an SPU 500 in the sense that it may 
use software to provide some or all of the processing 
resources provided in hardware and/or firmware by an SPU. 
HPE 655 in one preferred embodiment of the present 
invention is full-featured and fully compatible with SPE 
503 — that is, HPE 655 can handle each and every service 
call SPE 503 can handle such that the SPE and the HPE are 
"plug compatible" from an outside interface standpoint 
(with the exception that the HPE may not provide as much 
security as the SPE). 

HPEs 655 may be provided in two types: secure and not 
secure. For example, it may be desirable to provide non- 
secure versions of HPE 655 to allow electronic appliance 
600 to efficiently run non-sensitive VDE tasks using the full 
resources of a fast general purpose processor or computer. 
Such non-secure versions of HPE 655 may run under 
supervision of an instance of ROS 602 that also includes an 
SPE 503. In this way, ROS 602 may run all secure processes 
within SPE 503, and only use HPE 655 for processes that do 
not require security but that may require (or run more 
efficiently) under potentially greater resources provided by a 
general purpose computer or processor supporting HPE 655. 
Non-secure and secure HPE 655 may operate together with 
a secure SPE 503. 

HPEs 655 may (as shown in FIG. 10) be provided with a 
software-based tamper resistant barrier 674 that makes them 
more secure. Such a software-based tamper resistant barrier 
674 may be created by software executing on general- 
purpose CPU 654. Such a "secure" HPE 655 can be used by 
ROS 602 to execute processes that, while still needing 
security, may not require the degree of security provided by 
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SPU 500. This can be especially beneficial in architectures 
providing both an SPE 503 and an HPE 655. The SPU 502 
may be used to perform all truly secure processing, whereas 
one or more HPEs 655 may be used to provide additional 

5 secure (albeit possibly less secure than the SPE) processing 
using host processor or other general purpose resources that 
may be available within an electronic appliance 600. Any 
service may be provided by such a secure HPE 655. In the 
preferred embodiment, certain aspects of "channel process- 

10 nig" appears to be a candidate that could be readily exported 
from SPE 503 to HPE 655. 

The software-based tamper resistant barrier 674 provided 
by HPE 655 may be provided, for example, by: introducing 
time checks and/or code modifications to complicate the 

15 process of stepping through code comprising a portion of 
kernel 688a and/or a portion of component assemblies 690 
using a debugger; using a map of defects on a storage device 
(e.g., a hard disk, memory card, etc.) to form internal test 
values to impede moving and/or copying HPE 655 to other 

20 electronic appliances 600; using kernel code that contains 
false branches and other complications in flow of control to 
disguise internal processes to some degree from disassembly 
or other efforts to discover details of processes; using 
"self -generating" code (based on the output of a co-sine 

25 transform, for example) such that detailed and/or complete 
instruction sequences are not stored explicitly on storage 
devices and/or in active memory but rather are generated as 
needed; using code that "shuffles" memory locations used 
for data values based on operational parameters to compli- 

30 cate efforts to manipulate such values; using any software 
and/or hardware memory management resources of elec- 
tronic appliance 600 to "protect" the operation of HPE 655 
from other processes, functions, etc. Although such a 
software -based tamper resistant barrier 674 may provide a 

35 fair degree of security, it typically will not be as secure as the 
hardware-based tamper resistant barrier 502 provided (at 
least in part) by SPU 500. Because security may be better/ 
more effectively enforced with the assistance of hardware 
security features such as those provided by SPU 500 (and 

40 because of other factors such as increased performance 
provided by special purpose circuitry within SPU 500), at 
least one SPE 503 is preferred for many or most higher 
security applications. However, in applications where lesser 
security can be tolerated and/or the cost of an SPU 500 

45 cannot be tolerated, the SPE 503 may be omitted and all 
secure processing may instead be performed by one or more 
secure HPEs 655 executing on general-purpose CPUs 654. 
Some VDE processes may not be allowed to proceed on 
reduced-security electronic appliances of this type if insuf- 

50 ficient security is provided for the particular process 
involved. 

Only those processes that execute completely within SPEs 
503 (and in some cases, HPEs 655) may be considered to be 
truly secure. Memory and other resources external to SPE 

55 5 03 and HPEs 655 used to store and/or process code and/or 
data to be used in secure processes should only receive and 
handle that information in encrypted form unless SPE 503/ 
HPE 655 can protect secure process code and/or data from 
non-secure processes. 

60 OS "core" 679 in the preferred embodiment includes a 
kernel 680, an RPC manager 732, and an "object switch" 
734. API 682, HPE 655 and SPE 503 may communicate 
"event" messages with one another via OS "core" 679. They 
may also communicate messages directly with one another 

65 without messages going through OS "core" 679. 

Kernel 680 may manage the hardware of an electronic 
appliance 600, For example, it may provide appropriate 
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drivers and hardware managers for interacting with input/ 604 provided by API 682. To provide for this, ROS 602 may 

output and/or peripheral devices such as keyboard 612, include a "redirector" 684 that allows such "non-VDE 

display 614, other devices such as a "mouse" pointing aware" applications 608(6) to access VDE objects 300 and 

device and speech recognizer 613, modem 618, printer 622, functions 604. Redirector 684, in the preferred embodiment, 

and an adapter for network 672. Kernel 680 may also be 5 translates OS calls directed to the "other OS functions" 606 

responsible for initially loading the remainder of ROS 602, ^lo calls to the "VDE functions" 604. As one simple 

and may manage the various ROS tasks (and associated example, redirector 684 may intercept a "file open" call from 

underlying hardware resources) during execution. OS kernel application 608(6), determine whether the file to be opened 

680 may also manage and access secure database 610 and is contained within a VDE container 300, and if it is, 

file system 687. OS kernel 680 also provides execution 10 generate appropriate VDE function call(s) to file system 687 

services for applications 608a(l), 608a(2), etc. and other to °pen the VDE container (and potentially generate events 

applications. to HPE 655 and/or SPE 503 to determine the name(s) of 

RPC manager 732 performs messaging routing and file(s) that may be stored in a VDE object 300, establish a 

resource management/integration for ROS 680. It receives control structure associated with a VDE object 300, perform 

and routes "calls" from/to API 682, HPE 655 and SPE 503, 15 a registration for a VDE object 300, etc.). Without redirector 

for example. 684 in this example, a non-VDE aware application such as 

Object switch 734 may manage construction, deconstruc- 608i could access only the part of API 682 that provides an 

tion and other manipulation of VDE objects 300. interface to other OS functions 606, and therefore could not 

User Notification/Exception Interface 686 in the preferred access any VDE functions, 

embodiment (which may be considered part of API 682 or 20 This "translation" feature of redirector 684 provides 

another application coupled to the API) provides "pop up" "transparency." It allows VDE functions to be provided to 

windows/displays on display 614. This allows ROS 602 to the application 608(6) in a "transparent* ' way without requir- 

communicate directly with a user without having to pass m g the application to become involved in the complexity 

information to be communicated through applications 608. and details associated with generating the one or more calls 

For applications that are not "VDE aware," user notification/ 25 to ^ E functions 604. This aspect of the "transparency" 

exception interface 686 may provide communications features of ROS 602 has at least two important advantages: 

between ROS 602 and the user. (a) it allows applications not written specifically for VDE 

API 682 in the preferred embodiment provides a functions 604 ("non-VDE aware applications") to nev- 

standardized, documented software interface to applications ertheless access critical VDE functions; and 

608. In part, API 682 may translate operating system "calls" 30 (b) it reduces the complexity of the interface between an 

generated by applications 608 into Remote Procedure Calls application and ROS 602. 

("RPCs") specifying "events." RPC manager 732 may route Since the second advantage (reducing complexity) makes it 
these RPCs to kernel 680 or elsewhere (e.g., to HPE(s) 655 easier for an application creator to produce applications, 
and/or SPE(s) 503, or to remote electronic appliances 600, even "VDE aware" applications 608a(2) may be designed so 
processors, or VDE participants) for processing. The API 35 that some calls invoking VDE functions 604 are requested at 
682 may also service RPC requests by passing them to the level of an "other OS functions" call and then "trans- 
applications 608 that register to receive and process specific lated" by redirector 684 into a VDE function call (in this 
requests. sense, redirector 684 may be considered a part of API 682). 

API 682 provides an "Applications Programming later- FIG. UC shows an example of this. Other calls invoking 
face" that is preferably standardized and documented. It 40 VDE functions 604 may be passed directly without trans- 
provides a concise set of function calls an application lation by redirector 684. 

program can use to access services provided by ROS 602. In Referring again to FIG. 10, ROS 620 may also include an 

at least one preferred example, API 682 will include two "interceptor" 692 that transmits and/or receives one or more 

parts: an application program interface to VDE functions real time data feeds 694 (this may be provided over cable(s) 

604; and an application program interface to other OS 45 628 for example), and routes one or more such data feeds 

functions 606, These parts may be interwoven into the same appropriately while providing "translation" functions for 

software, or they may be provided as two or more discrete real time data sent and/or received by electronic appliance 

pieces of software (for example). 600 to allow "transparency" for this type of information 

Some applications, such as application 608a(l) shown in analogous to the transparency provided by redirector 684 
FIG. 11, may be "VDE aware" and may therefore directly 50 (and/or it may generate one or more real time data feeds), 
access both of these parts of API 682. FIG. 11A shows an Secure ROS Components and Component Assemblies 
example of this. A "VDE aware" application may, for As discussed above, ROS 602 in the preferred embodi- 
example, include explicit calls to ROS 602 requesting the men! is a component-based architecture. ROS VDE func- 
creation of new VDE objects 300, metering usage of VDE tions 604 may be based on segmented, independently load- 
objects, storing information in VDE-protected form, etc. 55 able executable "component assemblies" 690. These 
Thus, a "VDE aware" application can initiate (and, in some component assemblies 690 are independently securely 
examples, enhance and/or extend) VDE functionality pro- deliverable. The component assemblies 690 provided by the 
vided by ROS 602. In addition, "VDE aware" applications preferred embodiment comprise code and data elements that 
may provide a more direct interface between a user and ROS are themselves independently deliverable. Thus, each com- 
602 (e.g., by suppressing or otherwise dispensing with "pop 60 ponent assembly 690 provided by the preferred embodiment 
up" displays otherwise provided by user notification/ is comprised of independently securely deliverable elements 
exception interface 686 and instead providing a more "seam- which may be communicated using VDE secure communi- 
less" interface that integrates application and ROS cation techniques, between VDE secure subsystems, 
messages). These component assemblies 690 are the basic functional 

Other applications, such as application 6086 shown in 65 unit provided by ROS 602. The component assemblies 690 

FIG. 11B, may not be "VDE Aware" and therefore may not are executed to perform operating system or application 

"know" how to directly access an interface to VDE functions tasks. Thus, some component assemblies 690 may be con- 
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sidered to be part of the ROS operating system 602, while The component assembly organization provided by ROS 
other component assemblies may be considered to be "appli- 602 is "recursive" in that a component assembly 690 may 
cations" that run under the support of the operating system. comprise one or more component "subassemblies" that are 
As with any system incorporating "applications" and "oper- themselves independently loadable and executable compo- 
ating systems," the boundary between these aspects of an 5 nent assemblies 690. These component "subassemblies" 
overall system can be ambiguous. For example, commonly maV) m mrn( bc madc of onc or more component "sub-sub- 
used "application" functions (such as determining the struc- assemblies." In the general case, a component assembly 690 
hire and/or other attributes of a content container) may be indude N kvds of componcnt subassemblies, 
incorporated into an operating system. Furthermore, oper- ^ r . t , . nrt/fN At t 
ating system" functions (such as task management, or in Thus for example, a component assembly 690(A) that 
memory allocation) may be modified and/or replaced by an 10 ma y mcludes a component subassembly 690(k+l). Compo- 
application. A common thread in the preferred embodi- nent subassembly 690(k+l), in turn, may include a compo- 
ment's ROS 602 is that component assemblies 690 provide nent sub -sub -assembly 690(3), ... and so on to N-level 
functions needed for a user to fulfill her intended activities, subassembly 690(k+N). The ability of ROS 602 to build 
some of which may be "application-like" and some of which component assemblies 690 out of other component assem- 
may be "operating system-like." 15 blies provides great advantages in terms of, for example , 

Components 690 are preferably designed to be easily code/data reusability, and the ability to allow different 
separable and individually loadable. ROS 602 assembles parties to manage different parts of an overall component, 
these elements together into an executable component E acn component assembly 690 in the preferred embodi- 
assembly 690 prior to loading and executing the component ment ^ made of distinct components. FIGS. 11D-11H are 
assembly (e.g., in a secure operating environment such as 20 abstract depictions of various distinct components that may 
SPE 503 and/or HPE 655). ROS 602 provides an element b e assembled to form a component assembly 690(Jt) show- 
identification and referencing mechanism that includes mg FIG m These same components can be combined in 
mformation necessary to automatically assemble elements m&T&ni ways ( with more or i ess components) to form 
into a component assembly 690 in a secure manner prior to, different component assemblies 690 providing completely 
aD ^°o d ^ g ' executlon - 25 different functional behavior. FIG. 11J is an abstract depic- 

ROS 602 application structures and control parameters ^ of the same components being put together in a different 

used to form component assemblies 690 can be provided by way ( ^ actional components) to form a different 

different parties. Because the components forming compo- comp0 nent assembly 690(/). The component assemblies 

nent assemblies 690 are independently securely deliverable, 69Q(k) ^ m(j) ^ a m ^ 

they may be delivered at different times and/or by different 30 mterlocks ^ a "channel" 594 defined by ROS 602. This 

parties ("delivery;' may take place .within a local VDE secure "channel" 594 assembles component assemblies 690 and 

subsystem, that is submission through the use of such a interfaces them with the (rest of) ROS 602. 

secure subsystem of control information by a chain of n ~c. 4 ... . 

. 4 : . . - i * , ... ^. * A - . ROS 602 generates component assemblies 690 in a secure 

content control information handling participant for the A u u- n • ct/^c ht a h T , l 

c ji-a a * i • c *• * , « manner. As shown graphically in FIGS. Ill and 11J, the 

preparation of a modified control information set constitutes 35 . . * ■ * , ui mn 

f , . ji \t- i different elements comprising a component assembly 690 

independent, secure delivery). For example, a content ere- . «. „ , . . „ . & ; 4iL * 

, , nrxc enn v *• *u * j c it _ mav De interlocking in the sense that they can only go 

ator can produce a ROS 602 application that defines the t tU • *u f • * a a u *u imr ■ » 

. v j c i ■ • t , . j together in ways that are intended by the VDE participants 

circumstances required for licensing content contained r . a .u ^ * ai >* a ,u . 

... . . . . « nn .. - who created the elements and/or specified the component 

within a VDE object 300. This application may reference . r nrkC ... 4 4 £ t 

. . >aau *u o. up • assemblies. ROS 602 mcludes security protections that can 

structures provided by other parties. Such references might, 40 . t , . . * a-c • i 

c i . 1 *u r c * i iL *t. . f 1 prevent an unauthorized person from modifying elements, 

for example, take the form of a control path that uses content j i * ,l • j r l *•* »• 

creator sfcuctures to meter user activities; and structures *? d ^ *™ eat an unauthorized person from subsisting 

. , . a . . -j * l ji c -i elements. One can picture an unauthorized person making a 

created/owned by a financial provider to handle financial , . • . tt , „ *\, c f, 

e t # J 4***t»»* # .* / a a - new clement having the same shape as the one of the 

parts of a content distribution transaction (e.g.. defininc a , „ . %t^ c iir%«iTT j*L. 

a * u a ♦ *u * . u * • ; i * . * elements shown in FIGS. 11D-11H, and then attempting to 

credit budget that must be present in a control structure to 45 , ... , , . . , ' - • ■ i i 4 

ui- u a-* *u- „ a * i. . i_ substitute the new element in place or the original element, 

establish creditworthiness, audit processes which must be c C4U t # f « Tr , ^fU . u- u 

p , . v » \ a *u i Suppose one of the elements shown in FIG. 11H establishes 

performed by the licensee, etc.). As another example, a t u - c • * * -a.- imc u- * iaa rr 

j- , . J . f . , .. .. the pnee for using content within a VDE object 300. If an 

distributor may give one user more favorable pricing than , L . . b . . , , x , J u . „ . 

t , i j i ■ . j. ff „ . , , , t j c ■ unauthorized person could substitute her own price ele- 

another user by delivering different data elements defining t * tL • i , • * j j »i_ ^rCi- * , 

. . , , t, - „ 4 f r ment for the price element intended by the VDE content 

pricing to different users. This attribute of supporting mul- so . . , , . - 

f. , t • a a .i j r i_i * i • r distributor, then the person could establish a price of zero 

tiple party securely, independently deliverable control infor- . # . , . ,« , . 4 . r . 4 , , , 

t - * * 1, uv i * .t.\ instead of the price the content distributor intended to 

mation is fundamental to enabling electronic commerce, that . „. . r At _ , ^ 4 ... . . 4 

. , c . - . « j/ v . i • r \- charge. Similarly, if the element establishes an electronic 

is, defining of a content and/or appliance control mformation A % . J ' . t u .% • ^-«^ ♦ i 

' . * , . . . , c it ^ r • j credit card, then an ability to substitute a different element 

set that represents the requirements of a collection of inde- u L j- » • * r « ■ 

. 4 r . u « * . * *». could have disastrous consequences in terms of allowing a 
pendent parties such as content creators, other content 55 . , n , , / 
r m * -i ■ * j/ person to charge her usage to someone else s (or a non- 
providers, financial service providers, and/or users. ■ . *\ j-. , t*l i r * i 

... - , . j. # nnc t-i existent) credit card. These are merely a few simple 

In the preferred embodiment, ROS 602 assembles / , . ... . ; nnc£ni v 

i . j . 4 . j i * li i . • 4 examples demonstrating the importance of ROS 602 ensur- 

securely independently deliverable elements mto a compo- . . & . * j* 

„u u ^ * * . * / m g that certain component assemblies 690 are formed in a 

nent assembly 690 based in part on context parameters (e.g.. & n^om-. j -j r 

. \ ri. f _ , nrto ^r#u v , secure manner. ROS 602 provides a wide range of protec- 

object, user). Thus, for example, ROS 602 may securely 60 • 4 r«o. * «u u j.- 

J !, * t * * *L * c . tions against a wide range of "threats to the secure handling 

assemble different elements together to form different com- j *• r . Lr 

. i- £c\/\ c j o- 4 r • i and execution of component assemblies 690. 

ponent assemblies 690 for ditierent users performing the r 

same task on the same VDE object 300. Similarly, ROS 602 In me P referred embodiment, ROS 602 assembles corn- 
may assemble differing element sets which may include, that P° Qent «sscmWics 690 based on the following types of 
is reuse, one or more of the same components to form 65 e ^ ements ' 

different component assemblies 690 for the same user per- Permissions Records ("PERC's) 808; 

forming the same task on different VDE objects 300. Method "Cores" 1000; 
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Load Modules 1100; because of said other information's reference to one or more 

Data Elements (e.g., User Data Elements ("UDEs") 1200 sets of basic instructions and intrinsic data), whether or not 

and Method Data Elements ("MDEs") 1202); and said one or more sets of basic instructions and intrinsic data 

Other component assemblies 690. are accessible at any given point in time. 

Briefly, a PERC 808 provided by the preferred embodi- 5 Method core 1000* may be parameterized by an "event 

ment is a record corresponding to a VDE object 300 that code" to permit it to respond to different events in different 

identifies to ROS 602, among other things, the elements ways. For example, a METER method may respond to a 

ROS is to assemble together to form a component assembly "use" event by storing usage information in a meter data 

690. Thus PERC 808 in effect contains a "list of assembly structure. The same METER method may respond to an 

instructions" or a "plan" specifying what elements ROS 602 10 "administrative" event by reporting the meter data structure 

is to assemble together into a component assembly and how to a VDE clearinghouse or other VDE participant, 

the elements are to be connected together. PERC 808 may In the preferred embodiment, method core 1000' may 

itself contain data or other elements that are to become part "contain " either explicitly or by reference, one or more 

of the component assembly 690. "load modules" 1100 and one or more data elements (UDEs 

The PERC 808 may reference one or more method 15 1200, MDEs 1202). In the preferred embodiment, a "load 

"cores" 1000'. A method core 1000' may define a basic module" 1100 is a portion of a method that reflects basic 

"method" 1000 (e.g., "control," "billing," "metering," etc.) instructions and intrinsic data. Load modules 1100 in the 

In the preferred embodiment, a "method" 1000 is a preferred embodiment contain executable code, and may 

collection of basic instructions, and information related to also contain data elements ("DTDs" 1108) associated with 

basic instructions, that provides context, data, requirements, 20 the executable code. In the preferred embodiment, load 

and/or relationships for use in performing, and/or preparing modules 1100 supply the program instructions that are 

to perform, basic instructions in relation to the operation of actually "executed" by hardware to perform the process 

one or more electronic appliances 600. Basic instructions defined by the method. Load modules 1100 may contain or 

may be comprised of, for example: reference other load modules, 

machine code of the type commonly used in the program- 25 Load modules 1100 in the preferred embodiment are 

ming of computers; pseudo-code for use by an inter- modular and "code pure" so that individual load modules 

preter or other instruction processing program operat- may be reenterable and reusable. In order for components 

ing on a computer, 690 to be dynamically updatable, they may be individually 

a sequence of electronically represented logical opera- addressable within a global public name space. In view of 

tions for use with an electronic appliance 600; 30 these design goals, load modules 1100 are preferably small, 

or other electronic representations of instructions, source code (and code-like) pure modules that are individually 

code, object code, and/or pseudo code as those terms named and addressable. A single method may provide dif- 

are commonly understood in the arts. ferent load modules U00 that perform the same or similar 

Information relating to said basic instructions may functions on different platforms, thereby making the method 

comprise, for example, data associated intrinsically with 35 scalable and/or portable across a wide range of different 

basic instructions such as for example, an identifier for the electronic appliances. 

combined basic instructions and intrinsic data, addresses, UDEs 1200 and MDEs 1202 may store data for input to 

constants, and/or the like. The information may also, for or output from executable component assembly 690 (or data 

example, include one or more of the following: describing such inputs and/or outputs). In the preferred 

information that identifies associated basic instructions 40 embodiment, UDEs 1200 may be user dependent, whereas 

and said intrinsic data for access, correlation and/or MDEs 1202 ma y be user independent, 

validation purposes; T° e component assembly example 690(Jt) shown in FIG. 

required and/or optional parameters for use with basic llE a method core 1000', UDEs 1200a & 1200&, 

instructions and said intrinsic data; an MDE U02 > load modules llOOa-llOOd, and a further 

information defining relationships to other methods; 45 ™*°^?T$ biy 690 < k+1 )- M mentioned above a 

j , * . 4 . , A , - ' r PERC 808(/r) defines, among other things, the assembly 

data elements that may comprise data values, fields of • r P ' * ui /on/;\ j — 

. r . 1 ft ft ' instructions for component assembly 690(#), and may 

information, and/or the like; . . e *\ c « * *u / 

. , . Z . „ . contain or reference parts of some or all of the components 

information specifying and/or defining relationships ^ m to be 9SsmbM to crcate a co^^x assembly, 

among data elements, basic instructions and/or intrinsic 50 0ne of the load modules mob shown in this examp]e is 

. > . itself comprised of plural load modules 1100c, llOOd. Some 
information specifying relationships to external data ele- 0 f the load modules (e.g., 1100a, VLOOd) in this example 
ments i include one or more "DTD" data elements 1108 (e.g., 1108a, 
information specifying relationships between and among 11086). "DTD" data elements 1108 may be used, for 
internal and external data elements, methods, and/or the 55 example, to inform load module 1100a of the data elements 
like, if any exist; and included in MDE 1202 and/or UDEs 1200a, 12006. 
additional information required in the operation of basic Furthermore, DTDs 1108 may be used as an aspect of 
instructions and intrinsic data to complete, or attempt to forming a portion of an application used to inform a user as 
complete, a purpose intended by a user of a method, to the information required and/or manipulated by one or 
where required, including additional instructions and/ 60 more load modules 1100, or other component elements, 
or intrinsic data. Such an application program may also include functions for 
Such information associated with a method may be creating and/or manipulating UDE(s) 1200, MDE(s) 1202, 
stored, in part or whole, separately from basic instructions or other component elements, subassemblies, etc. 
and intrinsic data. When these components are stored Components within component assemblies 690 may be 
separately, a method may nevertheless include and encom- 65 "reused" to form different component assemblies. As men- 
pass the other information and one or more sets of basic tioned above, FIG. 11F is an abstract depiction of one 
instructions and intrinsic data (the latter being included example of the same components used for assembling 
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component assembly 690(Jt) to be reused (e.g., with some 
additional components specified by a different set of "assem- 
bly instructions" provided in a different PERC 808(/)) to 
form a different component assembly 690(1). Even though 
component assembly 690(/) is formed from some of the 5 
same components used to form component assembly 690(4), 
these two component assemblies may perform completely 
different processes in complete different ways. 

As mentioned above, ROS 602 provides several layers of 
security to ensure the security of component assemblies 690. 
One important security layer involves ensuring that certain 
component assemblies 690 are formed, loaded and executed 
only in secure execution space such as provided within an 
SPU 500. Components 690 and/or elements comprising 
them may be stored on external media encrypted using local 
SPU 500 generated and/or distributor provided keys. 15 

ROS 602 also provides a tagging and sequencing scheme 
that may be used within the loadable component assemblies 
690 to detect tampering by substitution. Each element com- 
prising a component assembly 690 may be loaded into an 
SPU 500, decrypted using encrypt/decrypt engine 522, and 20 
then tested/compared to ensure that the proper element has 
been loaded. Several independent comparisons may be used 
to ensure there has been no unauthorized substitution. For 
example, the public and private copies of the element ID 
may be compared to ensure that they are the same, thereby 25 
preventing gross substitution of elements. In addition, a 
validation/correlation tag stored under the encrypted layer of 
the loadable element may be compared to make sure it 
matches one or more tags provided by a requesting process. 
This prevents unauthorized use of information. As a third 30 
protection, a device assigned tag (e.g., a sequence number) 
stored under an encryption layer of a loadable element may 
be checked to make sure it matches a corresponding tag 
value expected by SPU 500. This prevents substitution of 
older elements. Validation/correlation tags are typically 35 
passed only in secure wrappers to prevent plaintext exposure 
of this information outside of SPU 500. 

The secure component based architecture of ROS 602 has 
important advantages. For example, it accommodates lim- 
ited resource execution environments such as provided by a 40 
lower cost SPU 500. It also provides an extremely high level 
of configurability. In fact, ROS 602 will accommodate an 
almost unlimited diversity of content types, content provider 
objectives, transaction types and client requirements. In 
addition, the ability to dynamically assemble independently 45 
deliverable components at execution time based on particu- 
lar objects and users provides a high degree of flexibility, 
and facilitates or enables a distributed database, processing, 
and execution environment. 

One aspect of an advantage of the component-based 50 
architecture provided by ROS 602 relates to the ability to 
"stage" functionality and capabilities over time. As 
designed, implementation of ROS 602 is a finite task. 
Aspects of its wealth of functionality can remain unex- 
ploited until market realities dictate the implementation of 55 
corresponding VDE application functionality. As a result, 
initial product implementation investment and complexity 
may be limited. The process of "surfacing" the full range of 
capabilities provided by ROS 602 in terms of authoring, 
administrative, and artificial intelligence applications may 60 
take place over time. Moreover, already -designed function- 
ality of ROS 602 may be changed or enhanced at any time 
to adapt to changing needs or requirements. 

More Detailed Discussion of Rights Operating System 
602 Architecture 65 

FIG. 12 shows an example of a detailed architecture of 
ROS 602 shown in FIG. 10, ROS 602 may include a file 
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system 687 that includes a commercial database manager 
730 and external object repositories 728. Commercial data- 
base manager 730 may maintain secure database 610. Object 
repository 728 may store, provide access to, and/or maintain 
VDE objects 300. 

FIG. 12 also shows that ROS 602 may provide one or 
more SPEs 503 and/or one or more HPEs 655. As discussed 
above, HPE 655 may "emulate" an SPU 500 device, and 
such HPEs 655 may be integrated in lieu of (or in addition 
to) physical SPUs 500 for systems that need higher through- 
put. Some security may be lost since HPEs 655 are typically 
protected by operating system security and may not provide 
truly secure processing. Thus, in the preferred embodiment, 
for high security applications at least, all secure processing 
should take place within an SPE 503 having an execution 
space within a physical SPU 500 rather than a HPE 655 
using software operating elsewhere in electronic appliance 
600. 

As mentioned above, three basic components of ROS 602 
are a kernel 680, a Remote Procedure Call (RPC) manager 
732 and an object switch 734. These components, and the 
way they interact with other portions of ROS 602, will be 
discussed below. 

Kernel 680 

Kernel 680 manages the basic hardware resources of 
electronic appliance 600, and controls the basic tasking 
provided by ROS 602. Kernel 680 in the preferred embodi- 
ment may include a memory manager 680a, a task manager 
6806, and an I/O manager 680c. Task manager 680b may 
initiate and/or manage initiation of executable tasks and 
schedule them to be executed by a processor on which ROS 
602 runs (e.g., CPU 654 shown in FIG. 8). For example, 
Task manager 6806 may include or be associated with a 
"bootstrap loader" that loads other parts of ROS 602. Task 
manager 6806 may manage all tasking related to ROS 602, 
including tasks associated with application program(s) 608. 
Memory manager 680a may manage allocation, 
deallocation, sharing and/or use of memory (e.g., RAM 656 
shown in FIG. 8) of electronic appliance 600, and may for 
example provide virtual memory capabilities as required by 
an electronic appliance and/or associated application^). I/O 
manager 680c may manage all input to and output from ROS 
602, and may interact with drivers and other hardware 
managers that provide communications and interactivity 
with physical devices. 

RPC Manager 732 

ROS 602 in a preferred embodiment is designed around a 
"services based" Remote Procedure Call architecture/ 
interface. All functions performed by ROS 602 may use this 
common interface to request services and share information. 
For example, SPE(s) 503 provide processing for one or more 
RPC based services. In addition to supporting SPUs 500, the 
RPC interface permits the dynamic integration of external 
services and provides an array of configuration options using 
existing operating system components. ROS 602 also com- 
municates with external services through the RPC interface 
to seamlessly provide distributed and/or remote processing. 
In smaller scale instances of ROS 602, a simpler message 
passing IPC protocol may be used to conserve resources. 
This may limit the configurability of ROS 602 services, but 
this possible limitation may be acceptable in some electronic 
appliances. 

The RPC structure allows services to be called/requested 
without the calling process having to know or specify where 
the service is physically provided, what system or device 
will service the request, or how the service request will be 
fulfilled. This feature supports families of services that may 
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be scaled and/or customized for specific applications. Ser- 
vice requests can be forwarded and serviced by different 
processors and/or different sites as easily as they can be 
forwarded and serviced by a local service system. Since the 
same RPC interface is used by ROS 602 in the preferred 5 
embodiment to request services within and outside of the 
operating system, a request for distributed and/or remote 
processing incurs substantially no additional operating sys- 
tem overhead. Remote processing is easily and simply 
integrated as part of the same service calls used by ROS 602 
for requesting local-based services. In addition, tie use of a 
standard RPC interface ("RSI") allows ROS 602 to be 
modularized, with the different modules presenting a stan- 
dardized interface to the remainder of the operating system. 
Such modularization and standardized interfacing permits 
different vendors/operating system programmers to create 15 
different portions of the operating system independently, and 
also allows the functionality of ROS 602 to be flexibly 
updated and/or changed based on different requirements 
and/or platforms. 

RPC manager 732 manages the RPC interface. It receives 20 
service requests in the form of one or more "Remote 
Procedure Calls'* (RPCs) from a service requestor, and 
routes the service requests to a service providers) that can 
service the request. For example, when rights operating 
system 602 receives a request from a user application via 2 s 
user API 682, RPC manager 732 may route the service 
request to an appropriate service through the "RPC service 
interface" ("RSI"). The RSI is an interface between RPC 
manager 732, service requestors, and a resource that will 
accept and service requests. 

The RPC interface (RSI) is used for several major ROS 
602 subsystems in the preferred embodiment. 

RPC services provided by ROS 602 in the preferred 
embodiment are divided into subservices, i.e., individual 
instances of a specific service each of which may be tracked 
individually by the RPC manager 732. This mechanism 35 
permits multiple instances of a specific service on higher 
throughput systems while maintaining a common interface 
across a spectrum of implementations. The subservice con- 
cept extends to supporting multiple processors, multiple 
SPEs 503, multiple HPEs 655, and multiple communica- 40 
tions services. 

The preferred embodiment ROS 602 provides the follow- 
ing RPC based service providers/requestors (each of which 
have an RPC interface or "RSI" that communicates with 
RPC manager 732): 45 
SPE device driver 736 (this SPE device driver is con- 
nected to an SPE 503 in the preferred embodiment); 
HPE Device Driver 738 (this HPE device driver is con- 
nected to an HPE 738 in the preferred embodiment); 
Notification Service 740 (this notification service is con- 50 
nected to user notification interface 686 in the preferred 
embodiment); 

API Service 742 (this API service is connected to user API 

682 in the preferred embodiment; 
Redirector 684; 

Secure Database (File) Manager 744 (this secure database 
or file manager 744 may connect to and interact with 
commercial database manager 730 and secure files 610 
through a cache manager 746, a database interface 748, 
and a database driver 750); 

Name Services Manager 752; 

Outgoing Administrative Objects Manager 754; 

Incoming Administrative Objects Manager 756; 

a Gateway 734 to object switch 734 (this is a path used to 65 
allow direct communication between RPC manager 
732 and Object Switch 734); and 
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Communications Manager 776. 

The types of services provided by HPE 655, SPE 503, 
User Notification 686, API 742 and Redirector 684 have 
already been described above. Here is a brief description of 
the type(s) of services provided by OS resources 744, 752, 
754, 756 and 776: 

Secure Database Manager 744 services requests for 

access to secure database 610; 
Name Services Manager 752 services requests relating to 

user, host, or service identification; 
Outgoing Administrative Objects Manager 754 services 

requests relating to outgoing administrative objects; 
Incoming Administrative Objects Manager 756 services 
requests relating to incoming administrative objects; 
and 

Communications Manager 776 services requests relating 
to communications between electronic appliance 600 
and the outside world. 

Object Switch 734 

Object switch 734 handles, controls and communicates 
(both locally and remotely) VDE objects 300. In the pre- 
ferred embodiment, the object switch may include the fol- 
lowing elements: 

a stream router 758; 

a real time stream interface^) 760 (which may be con- 
nected to real time data feed(s) 694); 

a time dependent stream interface(s) 762; 

a intercept 692; 

a container manager 764; 

one or more routing tables 766; and 

buffering/storage 768. 
Stream router 758 routes to/from "real time" and "time 
independent" data streams handled respectively by real time 
stream interface(s) 760 and time dependent stream interface 
(s) 762. Intercept 692 intercepts I/O requests that involve 
real-time information streams such as, for example, real time 
feed 694, The routing performed by stream router 758 may 
be determined by routing tables 766. Buffering/storage 768 
provides temporary store -and-forward, buffering and related 
services. Container manager 764 may (typically in conjunc- 
tion with SPE 503) perform processes on VDE objects 300 
such as constructing, deconstructing, and locating portions 
of objects. 

Object switch 734 communicates through an Object 
Switch Interface ("OSI") with other parts of ROS 602. The 
Object Switch Interface may resemble, for example, the 
interface for a Unix socket in the preferred embodiment. 
Each of the "OSI" interfaces shown in FIG. 12 have the 
ability to communicate with object switch 734. 

ROS 602 includes the following object switch service 
providers/resources (each of which can communicate with 
the object switch 734 through an "OSI"): 

Outgoing Administrative Objects Manager 754; 

Incoming Administrative Objects Manager 756; 

Gateway 734 (which may translate RPC calls into object 
switch calls and vice versa so RPC manager 732 may 
communicate with object switch 734 or any other 
element having an OSI to, for example, provide and/or 
request services); 

External Services Manager 772; 

Object Submittal Manager 774; and 

Communications Manager 776. 

Briefly, 

Object Repository Manager 770 provides services relat- 
ing to access to object repository 728; 
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External Services Manager 772 provides services relating 
to requesting and receiving services externally, such as 
from a network resource or another site; 
Object Submittal Manager 774 provides services relating 
to how a user application may interact with object s 
switch 734 (since the object submittal manager pro- 
vides an interface to an application program 608, it 
could be considered part of user API 682); and 
Communications Manager 776 provides services relating 

to communicating with the outside world. 30 
In the preferred embodiment, communications manager 
776 may include a network manager 780 and a mail gateway 
(manager) 782. Mail gateway 782 may include one or more 
mail filters 784 to, for example, automatically route VDE 
related electronic mail between object switch 734 and the 
outside world electronic mail services. External Services 
Manager 772 may interface to communications manager 776 
through a Service Transport Layer 786. Service Transport 
Layer 786a may enable External Services Manager 772 to 
communicate with external computers and systems using 
various protocols managed using the service transport layer 20 
786. 

The characteristics of and interfaces to the various sub- 
systems of ROS 680 shown in FIG. 12 are described in more 
detail below. 

RPC Manager 732 and Its RPC Services Interface 25 

As discussed above, the basic system services provided 
by ROS 602 are invoked by using an RPC service interface 
(RSI). This RPC service interface provides a generic, stan- 
dardized interface for different services systems and sub- 
systems provided by ROS 602. 30 

RPC Manager 732 routes RPCs requesting services to an 
appropriate RPC service interface. In the preferred 
embodiment, upon receiving an RPC call, RPC manager 732 
determines one or more service managers that are to service 
the request. RPC manager 732 then routes a service request 35 
to the appropriate service(s) (via a RSI associated with a 
service) for action by the appropriate service managers). 

For example, if a SPE 503 is to service a request, the RPC 
Manager 732 routes the request to RSI 736a, which passes 
the request on to SPE device driver 736 for forwarding to the 40 
SPE. Similarly, if HPE 655 is to service the request, RPC 
Manager 732 routes the request to RSI 738a for forwarding 
to a HPE. In one preferred embodiment, SPE 503 and HPE 
655 may perform essentially the same services so that RSIs 
736a, 738a are different instances of the same RSI. Once a 45 
service request has been received by SPE 503 (or HPE 655), 
the SPE (or HPE) typically dispatches the request internally 
using its own internal RPC manager (as will be discussed 
shortly). Processes within SPEs 503 and HPEs 655 can also 
generate RPC requests. These requests may be processed 50 
internally by a SPE/HPE, or if not internally serviceable, 
passed out of the SPE/HPE for dispatch by RPC Manager 
732. 

Remote (and local) procedure calls may be dispatched by 
a RPC Manager 732 using an "RPC Services Table/' An 55 
RPC Services Table describes where requests for specific 
services are to be routed for processing. Each row of an RPC 
Services Table in the preferred embodiment contains a 
services ID, the location of the service, and an address to 
which control will be passed to service a request. An RPC 60 
Services Table may also include control information that 
indicates which instance of the RPC dispatcher controls the 
service. Both RPC Manager 732 and any attached SPEs 503 
and HPEs 655 may have symmetric copies of the RPC 
Services Table. If an RPC service is not found in the RPC 65 
services tables, it is either rejected or passed to external 
services manager 772 for remote servicing. 
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Assuming RPC manager 732 finds a row corresponding to 
the request in an RPC Services Table, it may dispatch the 
request to an appropriate RSI. The receiving RSI accepts a 
request from the RPC manager 732 (which may have looked 
up the request in an RPC service table), and processes that 
request in accordance with internal priorities associated with 
the specific service. 

In the preferred embodiment, RPC Service Interface^) 
supported by RPC Manager 732 may be standardized and 
published to support add-on service modules developed by 
third party vendors, and to facilitate scalability by making it 
easier to program ROS 602, The preferred embodiment RSI 
closely follows the DOS and Unix device driver models for 
block devices so that common code may be developed for 
many platforms with minimum effort. An example of one 
possible set of common entry points are listed below in the 
table. 



Interface call 


Description 


SVC_LOAD 


Load a service manager and return 




its status. 


SVC_UNLOAD 


Unload a service manager. 


SVC_310UNT 


Mount (load) a dynamically loaded 




subservice and return its status. 


SVC_UNMOUNT 


Unmount (unload) a dynamically 




loaded subservice. 


SVC_OPEN 


Open a mounted subservice. 


SVC_CLOSE 


Close a mounted subservice. 


SVC_READ 


Read a block from an opened 




subservice. 


SVC_ WRITE 


Write a block to an opened 




subservice. 


SVC__IOCTL 


Control a subservice or a service 




manager. 



Load 

In the preferred embodiment, services (and the associated 
RSIs they present to RPC manager 732) may be activated 
during boot by an installation boot process that issues an 
RPC LOAD. This process reads an RPC Services Table from 
a configuration file, loads the service module if it is run time 
loadable (as opposed to being a kernel linked device driver), 
and then calls the LOAD entry point for the service. A 
successful return from the LOAJD entry point will indicate 
that the service has properly loaded and is ready to accept 
requests. 

RPC LOAD Call Example 

SVC_LOAD (long service_id) 

This LOAD interface call is called by the RPC manager 
732 during rights operating system 602 initialization. It 
permits a service manager to load any dynamically loadable 
components and to initialize any device and memory 
required by the service. The service number that the service 
is loaded as is passed in as service^id parameter. In the 
preferred embodiment, the service returns 0 is the initial- 
ization process was completed successfully or an error 
number if some error occurred. 

Mount 

Once a service has been loaded, it may not be fully 
functional for all subservices. Some subservices (e.g., com- 
munications based services) may require the establishment 
of additional connections, or they may require additional 
modules to be loaded. If the service is defined as 
"mountable a RPC manager 732 will call the MOUNT 
subservice entry point with the requested subservice ID prior 
to opening an instance of a subservice. 

RPC MOUNT Call Example 

SVC_MOUNT (long service_id, long subservice_id, 
BYTE 'buffer) 
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This MOUNT interface call instructs a service to make a 
specific subservice ready. This may include services related 
to networking, communications, other system services, or 
external resources. The service_id and subservice_id 
parameters may be specific to the specific service being 
requested. The buffer parameter is a memory address that 
references a control structure appropriate to a specific ser- 
vice. 

Open 

Once a service is loaded and "mounted," specific 
instances of a service may be "opened" for use. "Opening" 
an instance of a service may allocate memory to store 
control and status information. For example, in a BSD 
socket based network connection, a LOAD call will initial- 
ize the software and protocol control tables, a MOUNT call 
will specify networks and hardware resources, and an OPEN 
will actually open a socket to a remote installation. 

Some services, such as commercial database manager 730 
that underlies the secure database service, may not be 
"mountable." In this case, a LOAD call will make a con- 
nection to a database manager 730 and ensure that records 
are readable. An OPEN call may create instances of internal 
cache manager 746 for various classes of records. 

RPC OPEN Call Example 

SVC_OPEN (long service id, long subservice _jd, 

BYTE ""buffer, int (* receive) (long request_id)) 

This OPEN interface call instructs a service to open a 
specific subservice. The service_id and subservice_id 
parameters are specific to the specific service being 
requested, and the buffer parameter is a memory address that 
references a control structure appropriate to a specific ser- 
vice. 

The optional receive parameter is the address of a noti- 
fication callback function that is called by a service when- 
ever a message is ready for the service to retrieve it. One call 
to this address is made for each incoming message received. 
If the caller passes a NULL to the interface, the software will 
not generate a callback for each message. 

Close, Unmount and Unload 

The converse of the OPEN, MOUNT, and LOAD calls are 
CLOSE, UNMOUNT, and UNLOAD. These interface calls 
release any allocated resources back to ROS 602 (e.g., 
memory manager 680a). 

RPC CLOSE Call Example 

SVC_CLOSE (long svc_handle) 

This LOAD interface call closes an open service 
"handle." A service "handle" describes a service and sub- 
service that a user wants to close. The call returns 0 if the 
CLOSE request succeeds (and the handle is no longer valid) 
or an error number. 

RPC UNLOAD Call Example 

SVC_UNLOAD (void) 

This UNLOAD interface call is called by a RPC manager 
732 during shutdown or resource reallocation of rights 
operating system 602. It permits a service to close any open 
connections, flush buffers, and to release any operating 
system resources that it may have allocated. The service 
returns 0. 

RPC UNMOUNT Call Example 

SVC__UNMOUNT (long service _Jd, long subservice_ 

id) 

This UNMOUNT interface call instructs a service to 
deactivate a specific subservice. The service_Jd and 
subservice_id parameters are specific to the specific service 
being requested, and must have been previously mounted 
using the SVC J40UNT( ) request. The call releases all 
system resources associated with the subservice before it 
returns. 
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Read and Write 

The READ and WRITE calls provide a basic mechanism 
for sending information to and receiving responses from a 
mounted and opened service. For example, a service has 
requests written to it in the form of an RPC request, and 
makes its response available to be read by RPC Manager 732 
as they become available. 

RPC READ Call Example 

SVC_READ (long svc_handle, long request_id, BYTE 
♦buffer, long size) 

This READ call reads a message response from a service. 
The svc_handle and request_id parameters uniquely iden- 
tify a request. The results of a request will be stored in the 
user specified buffer up to size bytes. If the buffer is too 
small, the first size bytes of the message will be stored in the 
buffer and an error will be returned. 

If a message response was returned to the caller's buffer 
correctly, the function will return 0. Otherwise, an error 
message will be returned. 

RPC WRITE Call Example 

SVC_write (long service_id, long subservice _Jd, BYTE 
* buffer, long size, int (* receive) (long request_id) 

This WRITE call writes a message to a service and 
subservice specified by the service_id/subservice_id 
parameter pair. The message is stored in buffer (and usually 
conforms to the VDE RPC message format) and is size bytes 
long. The function returns the request id for the message (if 
it was accepted for sending) or an error number. If a user 
specifies the receive callback functions, all messages regard- 
ing a request will be sent to the request specific callback 
routine instead of the generalized message callback. 

Input/Output Control 

The IOCTL ("Input/Output Control") call provides a 
mechanism for querying the status of and controlling a 
loaded service. Elach service type will respond to specific 
general IOCTL requests, all required class IOCTL requests, 
and service specific IOCTL requests. 

RPC IOCTL Call Example 

ROI_SVC__IOCTL (long service_id, long subservice_ 
id, int command, BYTE *buffer) 

This IOCTL function provides a generalized control inter- 
face for a RSI. Auser specifies the service _Jd parameter and 
an optional subservice _Jd parameter that they wish to 
control. They specify the control command parameters), 
and a buffer into/from which the command parameters may 
be written/read. An example of a list of commands and the 
appropriate buffer structures are given below. 



Command 


Structure 


Description 


GET_INFO 


SVC_JNFO 


Returns information 






about a 






service/subservice. 


GET_STATS 


svc_stwts 


Returns current statistics 






about a 






service/subservice. 


CLR_STATS 


None 


Clears the statistics 






about a 






service/subservice. 



Now that a generic RPC Service Interface provided by the 
preferred embodiment has been described, the following 
description relates to particular examples of services pro- 
vided by ROS 602. 

SPE Device Driver 736 

SPE device driver 736 provides an interface between ROS 
602 and SPE 503. Since SPE 503 in the preferred embodi- 
ment runs within the confines of an SPU 500, one aspect of 
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this device driver 736 is to provide low level communica- 
tions services with the SPU 500 hardware. Another aspect of 
SPE device driver 736 is to provide an RPC service interface 
(RSI) 736a particular to SPE 503 (this same RSI may be 
used to communicate with HPE 655 through HPE device 
driver 738). 

SPE RSI 736a and driver 736 isolates calling processes 
within ROS 602 (or external to the ROS) from the detailed 
service provided by the SPE 503 by providing a set of basic 
interface points providing a concise function set. This has 
several advantages. For example, it permits a full line of 
scaled SPUs 500 that all provide common functionality to 
the outside world but which may differ in detailed internal 
structure and architecture. SPU 500 characteristics such as 
the amount of memory resident in the device, processor 
speed, and the number of services supported within SPU 500 
may be the decision of the specific SPU manufacturer, and 
in any event may differ from one SPU configuration to 
another. To maintain compatibility, SPE device driver 736 
and the RSI 736a it provides conform to a basic common 
RPC interface standard that "hides" differences between 
detailed configurations of SPUs 500 and/or the SPEs 503 
they may support. 

To provide for such compatibility, SPE RSI 736a in the 
preferred embodiment follows a simple block based stan- 
dard. In the preferred embodiment, an SPE RSI 736a may be 
modeled after the packet interfaces for network Ethernet 
cards. This standard closely models the block mode interface 
characteristics of SPUs 500 in the preferred embodiment. 

An SPE RSI 736a allows RPC calls from RPC manager 
732 to access specific services provided by an SPE 736. To 
do this, SPE RSI 736a provides a set of "service notification 
address interfaces." These provide interfaces to individual 
services provided by SPE 503 to the outside world. Any 
calling process within ROS 602 may access these SPE- 
provided services by directing an RPC call to SPE RSI 736a 
and specifying a corresponding "service notification 
address" in an RPC call. The specified "service notification 
address" causes SPE 503 to internally route an RPC call to 
a particular service within an SPE. The following is a listing 
of one example of a SPE service breakdown for which 
individual service notification addresses may be provided: 

Channel Services Manager 

Authentication Manager/Secure Communications Man- 
ager 

Secure Database Manager 

The Channel Services Manager is the principal service 
provider and access point to SPE 503 for the rest of ROS 
602. Event processing, as will be discussed later, is primarily 
managed (from the point of view of processes outside SPE 
503) by this service. The Authentication Manager/Secure 
Communications Manager may provide login/logout ser- 
vices for users of ROS 602, and provide a direct service for 
managing communications (typically encrypted or other- 
wise protected) related to component assemblies 690, VDE 
objects 300, etc. Requests for display of information (e.g., 
value remaining in a financial budget) may be provided by 
a direct service request to a Secure Database Manager inside 
SPE 503. The instances of Authentication Manager/Secure 
Communications Manager and Secure Database Manager, if 
available at all, may provide only a subset of the information 
and/or capabilities available to processes operating inside 
SPE 503. As stated above, most (potentially all) service 
requests entering SPE are routed to a Channel Services 
Manager for processing. As will be discussed in more detail 
later on, most control structures and event processing logic 
is associated with component assemblies 690 under the 
management of a Channel Services Manager. 



The SPE 503 must be accessed through its associated SPE 
driver 736 in this example. Generally, calls to SPE driver 
736 are made in response to RPC calls. In this example, SPE 
driver RSI 736a may translate RPC calls directed to control 
or ascertain information about SPE driver 736 into driver 
calls. SPE driver RSI 736a in conjunction with driver 736 
may pass RPC calls directed to SPE 503 through to the SPE. 

The following table shows one example of SPE device 
driver 736 calls: 
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Entry Point 



Description 



15 



20 



SPE_Jnfo() 

SPE_initialrze_iflterfaceQ 

SFE_terminatc_JnterfaceO 

SPE_reset_interfaceO 

SPE_get_stats() 

SPE_clear_jstats0 

SPE_set_noiify() 
SPE_gct_notify0 
SPE_tx_pkt0 



30 



Returns summary information 
about the SPE driver 736 (and SPE 
503) 

Initializes SPE driver 736, and sets 
the default notification address for 
received packets. 
Terminates SPE driver 736 and 
resets SPU 500 and the driver 736. 
Resets driver 736 without resetting 
SPU 500. 

Return statistics for notification 
addresses and/or an entire driver 
736. 

Clears statistics for a specific 

notification address and/or an 

entire driver 736. 

Sets a notification address for a 

specific service ID. 

Returns a notification address for a 

specific service ID. 

Sends a packet (e.g., containing an 

RPC call) to SPE 503 for 

processing. 



The following are more detailed examples of each of the 
SPE driver calls set forth in the table above. 
Example of an "SPE Information" Driver Call 
SPE_jnfo (void) 

This function returns a pointer to an SPE_JNFO data 
structure that defines the SPE device driver 736a. This data 
structure may provide certain information about SPE device 
driver 736, RSI 736a and/or SPU 500. An example of a 
SPE_INFO structure is described below: 
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Version Number/ID for SPE 
Device Driver 736 
Version Number/ID for SPE 
Device Driver RSr 736 
Pointer to name of SPE Device 
Driver 736 

Pointer to ID name of SPU 500 
Functionality Code Describing 
SPE Capabilities/functionality 



Example of an SPE "Initialize Interface" Driver Call 

SPEjiitialize interface (int (fen *receiver)(void)) 

A receiver function passed in by way of a parameter will 
be called for all packets received from SPE 503 unless their 
destination service is over-ridden using the set__notify( ) 
call. A receiver function allows ROS 602 to specify a format 
for packet communication between RPC manager 732 and 
SPE 503. 

This function returns "0" in the preferred embodiment if 
the initialization of the interface succeeds and non-zero if it 
fails. If the function fails, it will return a code that describes 
the reason for the failure as the value of the function. 

Example of an SPE "Terminate Interface" Driver Call 

SPE_terminate_Jnterface (void) 

In the preferred embodiment, this function shuts down 
SPE Driver 736, clears all notification addresses, and ter- 
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initiates all outstanding requests between an SPE and an 
ROS RPC manager 732. It also resets an SPE 503 (e.g., by 
a warm reboot of SPU 500) after all requests are resolved. 

Termination of driver 736 should be performed by ROS 
602 when the operating system is starting to shut down. It 
may also be necessary to issue this call if an SPE 503 and 
ROS 602 get so far out of synchronization that all processing 
in an SPE must be reset to a known state. 

Example of an SPE "Reset Interface" Driver Call 

SPE_reset_interface (void) 

This function resets driver 736, terminates all outstanding 
requests between SPE 503 and an ROS RPC manager 732, 
and clears all statistics counts. It does not reset the SPU 500, 
but simply restores driver 736 to a known stable state. 

Example of an SPE "Get Statistics" Driver Call 

SPE__get_stats (long service_Jd) 

This function returns statistics for a specific service 
notification interface or for the SPE driver 736 in general. It 
returns a pointer to a static buffer that contains these 
statistics or NULL if statistics are unavailable (either 
because an interface is not initialized or because a receiver 
address was not specified). An example of the SPE_STATS 
structure may have the following definition: 



Service id 

# packets rx 

# packets tx 

# bytes rx 

# bytes tx 

# errors rx 

# errors tx 

# requests tx 

# req tic completed 
U req tx cancelled 

# req rx 

# req rx completed 

# req rx cancelled 



If a user specifies a service ID, statistics associated with 
packets sent by that service are returned. If a user specified 
0 as the parameter, the total packet statistics for the interface 
are returned. 

Example of an SPE "Clear Statistics" Driver Call 

SPE_clear__stats (long service_Jd) 

This function clears statistics associated with the SPE 
service _id specified. If no servicc_id is specified (i.e., the 
caller passes in 0), global statistics will be cleared. The 
function returns 0 if statistics arc successfully cleared or an 
error number if an error occurs. 

Example of an SPE "Set Notification Address" Driver 
Call 

SPE_set__notify (long service_Jd, int (fen ^receiver) 
(void)) 

This function sets a notification address (receiver) for a 
specified service. If the notification address is set to NULL, 
SPE device driver 736 will send notifications for packets to 
the specified service to the default notification address. 

Example of a SPE "Get Notification Address" Driver Call 

SPE_get_notify (long service__id) 

This function returns a notification address associated 
with the named service or NULL if no specific notification 
address has been specified. 

Example of an SPE "Send Packet" Driver Call 

send_pkt (BYTE 'buffer, long size, int (far "receive) 
(void)) 

This function sends a packet stored in buffer of "length" 
size. It returns 0 if the packet is sent successfully, or returns 
an error code associated with the failure. 
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Redirector Service Manager 684 

The redirector 684 is a piece of systems integration 
software used principally when ROS 602 is provided by 
"adding on" to a pre-existing operating system or when 

5 "transparent" operation is desired for some VDE functions, 
as described earlier. In one embodiment the kernel 680, part 
of communications manager 776, file system 687, and part 
of API service 742 may be part of a pre-existing operating 
system such as DOS, Windows, UNIX, Macintosh System, 

10 OS9, PSOS, OS/2, or other operating system platform. The 
remainder of ROS 602 subsystems shown in FIG. 12 may be 
provided as an "add on" to a preexisting operating system. 
Once these ROS subsystems have been supplied and "added 

15 on," the integrated whole comprises the ROS 602 shown in 
FIG. 12. 

In a scenario of this type of integration, ROS 602 will 
continue to be supported by a preexisting OS kernel 680, but 
may supplement (or even substitute) many of its functions 

20 by providing additional add-on pieces such as, for example, 
a virtual memory manager. 

Also in this integration scenario, an add-on portion of API 
service 742 that integrates readily with a preexisting API 
service is provided to support VDE function calls. A pre- 

25 existing API service integrated with an add-on portion 
supports an enhanced set of operating system calls including 
both calls to VDE functions 604 and calls to functions 606 
other than VDE functions (see FIG. 11A). The add-on 
portion of API service 742 may translate VDE function calls 

30 into RPC calls for routing by RPC manager 732. 

ROS 602 may use a standard communications manager 
776 provided by the preexisting operating system, or it may 
provide "add ons" and/or substitutions to it that may be 
readily integrated into it. Redirector 684 may provide this 

35 integration function. 

This leaves a requirement for ROS 602 to integrate with 
a preexisting file system 687. Redirector 684 provides this 
integration functioa 

In this integration scenario, file system 687 of the preex- 

40 isting operating system is used for all accesses to secondary 
storage. However, VDE objects 300 may be stored on 
secondary storage in the form of external object repository 
728, file system 687, or remotely accessible through com- 
munications manager 776. When object switch 734 wants to 

45 access external object repository 728, it makes a request to 
the object repository manager 770 that then routes the 
request to object repository 728 or to redirector 692 (which 
in turn accesses the object in file system 687). 

Generally, redirector 684 maps VDE object repository 

50 728 content into preexisting calls to file system 687. The 
redirector 684 provides preexisting OS level information 
about a VDE object 300, including mapping the object into 
a preexisting OS's name space. This permits seamless access 
to VDE protected content using "normal" file system 687 

55 access techniques provided by a preexisting operating sys- 
tem. 

In the integration scenarios discussed above, each preex- 
isting target OS file system 687 has different interface 
requirements by which the redirector mechanism 684 may 

60 be "hooked." In general, since all commercially viable 
operating systems today provide support for network based 
volumes, file systems, and other devices (e.g., printers, 
modems, etc.), the redirector 684 may use low level network 
and file access "hooks" to integrate with a preexisting 

65 operating system. "Add-ons" for supporting VDE functions 
602 may use these existing hooks to integrate with a 
preexisting operating system. 
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User Notification Service Manager 740 

User Notification Service Manager 740 and associated 
user notification exception interface ("pop up") 686 provides 
ROS 602 with an enhanced ability to communicate with a 
user of electronic appliance 600. Not all applications 608 
may be designed to respond to messaging from ROS 602 
passed through API 682, and it may in any event be 
important or desirable to give ROS 602 the ability to 
communicate with a user no matter what state an application 
is in. User notification services manager 740 and interface 
686 provides ROS 602 with a mechanism to communicate 
directly with a user, instead of or in addition to passing a 
return call through API 682 and an application 608. This is 
similar, for example, to the ability of the Windows operating 
system to display a user message in a "dialog box" that 
displays "on top of a running application irrespective of the 
state of the application. 

The User Notification 686 block in the preferred embodi- 
ment may be implemented as application code. The imple- 
mentation of interface 740a is preferably built over notifi- 
cation service manager 740, which may be implemented as 
part of API service manager 742. Notification services 
manager 740 in the preferred embodiment provides notifi- 
cation support to dispatch specific notifications to an appro- 
priate user process via the appropriate API return, or by 
another path. This mechanism permits notifications to be 
routed to any authorized process — not just back to a process 
that specified a notification mechanism. 

API Service Manager 742 

The preferred embodiment API Service Manager 742 is 
implemented as a service interface to the RPC service 
manager 732. All user API requests are built on top of this 
basic interface. The API Service Manager 742 preferably 
provides a service instance for each running user application 
608. 

Most RPC calls to ROS functions supported by API 
Service Manager 742 in the preferred embodiment may map 
directly to service calls with some additional parameter 
checking. This mechanism permits developers to create their 
own extended API libraries with additional or changed 
functionality. 

In the scenario discussed above in which ROS 602 is 
formed by integrating "add ons" with a preexisting operating 
system, the API service 742 code may be shared (e.g., 
resident in a host environment like a Windows DLL), or it 
may be directly linked with an applications^ code — 
depending on an application programmer's implementation 
decision, and/or the type of electronic appliance 600. The 
Notification Service Manager 740 may be implemented 
within API 682. Tfcese components interface with Notifica- 
tion Service component 686 to provide a transition between 
system and user space. 

Secure Database Service Manager ("SDSM") 744 

There are at least two ways that may be used for managing 
secure database 600: 

a commercial database approach, and 

a site record number approach. 
Which way is chosen may be based on the number of records 
that a VDE site stores in the secure database 610. 

The commercial database approach uses a commercial 
database to store securely wrappered records in a commer- 
cial database. This way may be preferred when there are a 
large number of records that are stored in the secure database 
610. This way provides high speed access, efficient updates, 
and easy integration to host systems at the cost of resource 
usage (most commercial database managers use many sys- 
tem resources). 
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The site record number approach uses a "site record 
number" ("SRN") to locate records in the system. This 
scheme is preferred when the number of records stored in the 
secure database 610 is small and is not expected to change 
5 extensively over time. This way provides efficient resources 
use with limited update capabilities. SRNs permit further 
grouping of similar data records to speed access and increase 
performance. 

Since VDE 100 is highly scalable, different electronic 
10 appliances 600 may suggest one way more than the other. 
For example, in limited environments like a set top, PDA, or 
other low end electronic appliance, the SRN scheme may be 
preferred because it limits the amount of resources (memory 
and processor) required. When VDE is deployed on more 
15 capable electronic appliances 600 such as desktop 
computers, servers and at clearinghouses, the commercial 
database scheme may be more desirable because it provides 
high performance in environments where resources are not 
limited. 

20 One difference between the database records in the two 
approaches is whether the records are specified using a full 
VDE ID or SRN. To translate between the two schemes, a 
SRN reference may be replaced with a VDE ID database 
reference wherever it occurs. Similarly, VDE IDs that are 

25 used as indices or references to other items may be replaced 
by the appropriate SRN value. 

In the preferred embodiment, a commercially available 
database manager 730 is used to maintain secure database 
610. ROS 602 interacts with commercial database manager 

30 730 through a database driver 750 and a database interface 
748. The database interface 748 between ROS 602 and 
external, third party database vendors' commercial database 
manager 730 may be an open standard to permit any 
database vendor to implement a VDE compliant database 

35 driver 750 for their products. 

ROS 602 may encrypt each secure database 610 record so 
that a VDE-provided security layer is "on top of the 
commercial database structure. In other words, SPE 736 
may write secure records in sizes and formats that may be 

40 stored within a database record structure supported by 
commercial database manager 730. Commercial database 
manager 730 may then be used to organize, store, and 
retrieve the records. In some embodiments, it may be 
desirable to use a proprietary and/or newly created database 

45 manager in place of commercial database manager 730. 
However, the use of commercial database manager 730 may 
provide certain advantages such as, for example, an ability 
to use already existing database management produces). 
The Secure Database Services Manager ("SDSM") 744 

50 makes calls to an underlying commercial database manager 
730 to obtain, modify, and store records in secure database 
610. In the preferred embodiment, "SDSM" 744 provides a 
layer "on top of the structure of commercial database 
manager 730. For example, all VDE-secure information is 

55 sent to commercial database manager 730 in encrypted form. 
SDSM 744 in conjunction with cache manager 746 and 
database interface 748 may provide record management, 
caching (using cache manager 746), and related services (on 
top of) commercial database systems 730 and/or record 

60 managers. Database Interface 748 and cache manager 746 in 
the preferred embodiment do not present their own RSI, but 
rather the RPC Manager 732 communicates to them through 
the Secure Database Manager RSI 744a. 
Name Services Manager 752 

65 The Name Services Manager 752 supports three subser- 
vices: user name services, host name services, and services 
name services. User name services provides mapping and 
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lookup between user name and user ID numbers, and may 754 typically maintains records (in concert with SPE 503) in 

also support other aspects of user-based resource and infor- secure database 610 (e.g., shipping table 444) that reflect 

mation security. Host name services provides mapping and when objects have been successfully transmitted, when an 

lookup between the names (and other information, such as object should be transmitted, and other information related 

for example address, communications connection/routing 5 to transmission of objects, 

information, etc.) of other processing resources (e.g., other Incoming Administrative Object Manager 756 

host electronic appliances) and VDE node IDs. Services Incoming administrative object manager 756 receives 

name service provides a mapping and lookup between atainistrative 0 * ? -if cte .^ roin ot ^ er VDE electronic appliances 

services names and other pertinent information such as 6 °? via communications manager 776. It may route the 

. f t . t . , . , . object to object repository manager 770, object switch 734 

connection information (e.g., remotely available service 10 J j T • j • • ' *■ u* * 

, * 4 • r ?• \ j • m or other destination. Incoming administrative object man- 

routing and contact mformation) and service IDs. ?s6 ^ * cords (k ^ sp£ 

Name Services Manager 752 in the preferred embodiment ^ in ^ 610 ( uMc U6) ^ 

is connected to External Services Manager 772 so that it may rec0 ' rd whkh objects have been veaiivc6f objects expected 

provide external service routing information directly to the for rcccipt? md othcr information rc i atcd to Kccivcd md/oT 

external services manager. Name services manager 752 is is expected objects, 

also connected to secure database manager 744 to permit the Object Repository Manager 770 

name services manager 752 to access name services records Object repository manager 770 is a form of database or 

stored within secure database 610. file manager. It manages the storage of VDE objects 300 in 

External Services Manager 772 & Services Transport object repository 728, in a database, or in the file system 687. 

Layer 786 20 Object repository manager 770 may also provide the ability 

The External Services Manager 772 provides protocol to browse and/or search information related to objects (such 

support capabilities to interface to external service provid- as summaries of content, abstracts, reviewers' commentary, 

ers. External services manager 772 may, for example, obtain schedules, promotional materials, etc.), for example, by 

external service routing information from name services using INFORMATION methods associated with VDE 

manager 752, and then initiate contact to a particular exter- 25 0D J ects 

nal service (e.g., another VDE electronic appliance 600, a 0b i cct Submittal Manager 774 

financial clearinghouse, etc.) through communications man- ° b i ect submittal manager 774 in the preferred embodi- 

ager 776. External services manager 772 uses a service m u ent P r0Vlde u s ™ mter * ac * betwee V 11 application 608 and 

transport layer 786 to supply communications protocols and object switch 734 and thus may be considered m some 

other information necessary to provide communications. 30 ^pects part of AP 682. For example it may a low a user 

i . * j. t * application to create new VDE objects 300. It may also 

There are several important examples of the use of al £ w incoming/cmtgoirjg administrative object managers 

External Services Manager 772. Some VDE objects may 756> 754 to create VDE ob j e cts300 (administrative objects), 

have some or all of their content stored at an Object FIG. 12A shows how object submittal manager 774 may 

Repository 728 on an electronic appliance 600 other than the fc e use d t0 communicate with a user of electronic appliance 

one operated by a user who has, or wishes to obtain, some 35 500 to help to create a new VDE object 300. FIG. 12Ashows 

usage rights to such VDE objects. In this case, External that object creation may occur in two stages in the preferred 

Services Manager 772 may manage a connection to the embodiment: an object definition stage 1220, and an object 

electronic appliance 600 where the VDE objects desired (or creation stage 1230. The role of object submittal manager 

their content) is stored. In addition, file system 687 may be 774 is indicated by the two different "user input" depictions 

a network file system (e.g., Netware, LANtastic, NFS, etc.) 40 (774(1), 774(2)) shown in FIG. 12A. 

that allows access to VDE objects using redirecter 684. In one of its roles or instances, object submittal manager 

Object switch 734 also supports this capability. 774 provides a user interface 774a that allows the user to 

If External Services Manager 772 is used to access VDE create an object configuration file 1240 specifying certain 

objects, many different techniques are possible. For characteristics of a VDE object 300 to be created. This user 

example, the VDE objects may be formatted for use with the 45 interface 774a may, for example, allow the user to specify 

World Wide Web protocols (HTML, HTTP, and URL) by that she wants to create an object, allow the user to designate 

including relevant headers, content tags, host ID to URL the content the object will contain, and allow the user to 

conversion (e.g., using Name Services Manager 752) and an specify certain other aspects of the information to be con- 

HTTP-aware instance of Services Transport Layer 786. tained within the object (e.g., rules and control information, 

In other examples, External Services Manager 772 may 50 identifying information, etc.). 

be used to locate, connect to, and utilize remote event Part of the object definition task 1220 in the preferred 

processing services; smart agent execution services (both to embodiment may be to analyze the content or other infor- 

provide these services and locate them); certification ser- mation to be placed within an object. Object definition user 

vices for Public Keys; remote Name Services; and other interface 774o may issue calls to object switch 734 to 

remote functions either supported by ROS 602 RPCs (e.g., 55 analyze "content" or other information that is to be included 

have RSIs), or using protocols supported by Services Trans- within the object to be created in order to define or organize 

port Layer 786. the content into "atomic elements" specified by the user. As 

Outgoing Administrative Object Manager 754 explained elsewhere herein, such "atomic element" organi- 

Outgoing administrative object manager 754 receives zations might, for example, break up the content into 

administrative objects from object switch 734, object reposi- 60 paragraphs, pages or other subdivisions specified by the 

tory manager 770 or other source for transmission to another user, and might be explicit (e.g., inserting a control character 

VDE electronic appliance. Outgoing administrative object between each "atomic element") or implicit. Object switch 

manager 754 takes care of sending the outgoing object to its 734 may receive static and dynamic content (e.g., by way of 

proper destination. Outgoing administrative object manager time independent stream interface 762 and real time stream 

754 may obtain routing information from name services 65 interface 760), and is capable of accessing and retrieving 

manager 752, and may use communications service 776 to stored content or other information stored within file system 

send the object. Outgoing administrative object manager 687. 
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The result of object definition 1240 may be an object 
configuration file 1240 specifying certain parameters relat- 
ing to the object to be created. Such parameters may include, 
for example, map tables, key management specifications, 
and event method parameters. The object construction stage 5 
1230 may take the object configuration file 1240 and the 
information or content to be included within the new object 
as input, construct an object based on these inputs, and store 
the object within object repository 728. 

Object construction stage 1230 may use information in 10 
object configuration file 1240 to assemble or modify a 
container. This process typically involves communicating a 
series of events to SPE 503 to create one or more PERCs 
808, public headers, private headers, and to encrypt content, 
all for storage in the new object 300 (or within secure is 
database 610 within records associated with the new object). 

The object configuration file 1240 may be passed to 
container manager 764 within object switch 734. Container 
manager 734 is responsible for constructing an object 300 
based on the object configuration file 1240 and further user 20 
input. The user may interact with the object construction 
1230 through another instance 774(2) of object submittal 
manager 774. In this further user interaction provided by 
object submittal manager 774, the user may specify 
permissions, rules and/or control information to be applied 25 
to or associated with the new object 300. To specify 
permissions, rules and control information, object submittal 
manager 774 and/or container manager 764 within object 
switch 734 generally will, as mentioned above, need to issue 
calls to SPE 503 (e.g., through gateway 734) to cause the 30 
SPE to obtain appropriate information from secure database 
610, generate appropriate database items, and store the 
database items into the secure database 610 and/or provide 
them in encrypted, protected form to the object switch for 
incorporation into the object. Such information provided by 35 
SPE 503 may include, in addition to encrypted content or 
other information, one or more PERCs 808, one or more 
method cores 1000', one or more load modules 1100, one or 
more data structures such as UDEs 1200 and/or MDEs 1202, 
along with various key blocks, tags, public and private 40 
headers, and error correction information. 

The container manager 764 may, in cooperation with SPE 
503, construct an object container 302 based at least in part 
on parameters about new object content or other information 
as specified by object configuration file 1240. Container 45 
manager 764 may then insert into the container 302 the 
content or other information (as encrypted by SPE 503) to be 
included in the new object. Container manager 764 may also 
insert appropriate permissions, rules and/or control infor- 
mation into the container 302 (this permissions, rules and/or 50 
control information may be defined at least in part by user 
interaction through object submittal manager 774, and may 
be processed at least in part by SPE 503 to create secure data 
control structures). Container manager 764 may then write 
the new object to object repository 687, and the user or the 55 
electronic appliance may "register" the new object by 
including appropriate information within secure database 
610. 

Communications Subsystem 776 

Communications subsystem 776, as discussed above, may 60 
be a conventional communications service that provides a 
network manager 780 and a mail gateway manager 782. 
Mail filters 784 may be provided to automatically route 
objects 300 and other VDE information to/from the outside 
world. Communications subsystem 776 may support a real 65 
time content feed 684 from a cable, satellite or other 
telecommunications link. 
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Secure Processing Environment 503 

As discussed above in connection with FIG. 12, each 
electronic appliance 600 in the preferred embodiment 
includes one or more SPEs 503 and/or one or more HPEs 
655. These secure processing environments each provide a 
protected execution space for performing tasks in a secure 
manner. They may fulfill service requests passed to them by 
ROS 602, and they may themselves generate service 
requests to be satisfied by other services within ROS 602 or 
by services provided by another VDE electronic appliance 
600 or computer. 

In the preferred embodiment, an SPE 503 is supported by 
the hardware resources of an SPU 500. An HPE 655 may be 
supported by general purpose processor resources and rely 
on software techniques for security/protection. HPE 655 
thus gives ROS 602 the capability of assembling and execut- 
ing certain component assemblies 690 on a general purpose 
CPU such as a microcomputer, minicomputer, mainframe 
computer or supercomputer processor. In the preferred 
embodiment, the overall software architecture of an SPE 
503 may be the same as the software architecture of an HPE 
655. An HPE 655 can "emulate" SPE 503 and associated 
SPU 500, i.e., each may include services and resources 
needed to support an identical set of service requests from 
ROS 602 (although ROS 602 may be restricted from sending 
to an HPE certain highly secure tasks to be executed only 
within an SPU 500). 

Some electronic appliance 600 configurations might 
include both an SPE 503 and an HPE 655. For example, the 
HPE 655 could perform tasks that need lesser (or no) 
security protections, and the SPE 503 could perform all tasks 
that require a high degree of security. This ability to provide 
serial or concurrent processing using multiple SPE and/or 
HPE arrangements provides additional flexibility, and may 
overcome limitations imposed by limited resources that can 
practically or cost-effectively be provided within an SPU 
500. The cooperation of an SPE 503 and an HPE 655 may, 
in a particular application, lead to a more efficient and cost 
effective but nevertheless secure overall processing environ- 
ment for supporting and providing the secure processing 
required by VDE 100. As one example, an HPE 655 could 
provide overall processing for allowing a user to manipulate 
released object 300 'contents,* but use SPE 503 to access the 
secure object and release the information from the object. 

FIG. 13 shows the software architecture of the preferred 
embodiment Secure Processing Environment (SPE) 503. 
This architecture may also apply to the preferred embodi- 
ment Host Processing Environment (HPE) 655. "Protected 
Processing Environment" ("PPE") 650 may refer generally 
to SPE 503 and/or HPE 655. Hereinafter, unless context 
indicates otherwise, references to any of "PPE 650/' "HPE 
655" and "SPE 503" may refer to each of them. 

As shown in FIG. 13, SPE 503 (PPE 650) includes the 
following service managers/major functional blocks in the 
preferred embodiment: 

Kernel/Dispatcher 552 

Channel Services Manager 562 

SPE RPC Manager 550 

Time Base Manager 554 

Encryption/Decryption Manager 556 

Key and Tag Manager 558 

Summary Services Manager 560 

Authentication Manager/Service Communications Man- 
ager 564 
Random Value Generator 565 
Secure Database Manager 566 
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Other Services 592. 

Each of the major functional blocks of PPE 650 is 
discussed in detail below. 
I. SPE Kernel/Dispatcher 552 

The Kernel/Dispatcher 552 provides an operating system 
"kernel" that runs on and manages the hardware resources of 
SPU 500. This operating system "kernel*' 552 provides a 
self-contained operating system for SPU 500; it is also a part 
of overall ROS 602 (which may include multiple OS 
kernels, including one for each SPE and HPE ROS is 
controlling/managing). Kernel/dispatcher 552 provides SPU 
task and memory management, supports internal SPU hard- 
ware interrupts, provides certain "low level services," man- 
ages "DTD" data structures, and manages the SPU bus 
interface unit 530. Kernel/dispatcher 552 also includes a 
load module execution manager 568 that can Load programs 
into secure execution space for execution by SPU 500. 

In the preferred embodiment, kernel/dispatcher 552 may 
include the following software/functional components: 

load module execution manager 568 

task manager 576 

memory manager 578 

virtual memory manager 580 

"low level" services manager 582 

internal interrupt handlers 584 

BIU handler 586 (may not be present in HPE 655) 

Service interrupt queues 588 

DTD Interpreter 590. 

At least parts of the kernel/dispatcher 552 are preferably 
stored in SPU firmware loaded into SPU ROM 532. An 
example of a memory map of SPU ROM 532 is shown in 
FIG. 14A. This memory map shows the various components 
of kernel/dispatcher 552 (as well as the other SPE services 
shown in FIG. 13) residing in SPU ROM 532a and/or 
EEPROM 532b. The FIG. 14B example of an NVRAM 
534/? memory map shows the task manager 576 and other 
information loaded into NVRAM. 

One of the functions performed by kernel/dispatcher 552 
is to receive RPC calls from ROS RPC manager 732. As 
explained above, the ROS Kernel RPC manager 732 can 
route RPC calls to the SPE 503 (via SPE Device Driver 736 
and its associated RSI 736a) for action by the SPE. The SPE 
kernel/dispatcher 552 receives these calls and either handles 
them or passes them on to SPE RPC manager 550 for routing 
internally to SPE 503. SPE 503 based processes can also 
generate RPC requests. Some of these requests can be 
processed internally by the SPE 503. If they are not inter- 
nally serviceable, they may be passed out of the SPE 503 
through SPE kernel/dispatcher 552 to ROS RPC manager 
732 for routing to services external to SPE 503. 

A. Kernel/Dispatcher Task Management 

Kernel/dispatcher task manager 576 schedules and over- 
sees tasks executing within SPE 503 (PPE 650). SPE 503 
supports many types of tasks. A "channel" (a special type of 
task that controls execution of component assemblies 690 in 
the preferred embodiment) is treated by task manager 576 as 
one type of task. Tasks are submitted to the task manager 
576 for execution. Task manager 576 in turn ensures that the 
SPE 503/SPU 500 resources necessary to execute the tasks 
are made available, and then arranges for the SPU micro- 
processor 520 to execute the task. 

Any call to kernel/dispatcher 552 gives the kernel an 
opportunity to take control of SPE 503 and to change the 
task or tasks that are currently executing. Thus, in the 
preferred embodiment kernel/dispatcher task manager 576 
may (in conjunction with virtual memory manager 580 
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and/or memory manager 578) "swap out" of the execution 
space any or all of the tasks that are currently active, and 
"swap in" additional or different tasks. 

SPE tasking managed by task manager 576 may be either 

5 "single tasking" (meaning that only one task may be active 
at a time) or "multi -tasking" (meaning that multiple tasks 
may be active at once). SPE 503 may support single tasking 
or multi-tasking in the preferred embodiment. For example, 
"high end" implementations of SPE 503 (e.g., in server 

10 devices) should preferably include multi-tasking with "pre- 
emptive scheduling." Desktop applications may be able to 
use a simpler SPE 503, although they may still require 
concurrent execution of several tasks. Set top applications 
may be able to use a relatively simple implementation of 

15 SPE 503, supporting execution of only one task at a time. 
For example, a typical set top implementation of SPU 500 
may perform simple metering, budgeting and billing using 
subsets of VDE methods combined into single "aggregate" 
load modules to permit the various methods to execute in a 

20 single tasking environment. However, an execution envi- 
ronment that supports only single tasking may limit use with 
more complex control structures. Such single tasking ver- 
sions of SPE 503 trade flexibility in the number and types of 
metering and budgeting operations for smaller run time 

25 RAM size requirements. Such implementations of SPE 503 
may (depending upon memory limitations) also be limited to 
metering a single object 300 at a time. Of course, variations 
or combinations are possible to increase capabilities beyond 
a simple single tasking environment without incurring the 

30 additional cost required to support "full multitasking." 

In the preferred embodiment, each task in SPE 503 is 
represented by a "swap block," which may be considered a 
"task" in a traditional multitasking architecture, A "swap 
block" in the preferred embodiment is a bookkeeping 

35 mechanism used by task manager 576 to keep track of tasks 
and subtasks. It corresponds to a chunk of code and asso- 
ciated references that "fits" within the secure execution 
environment provided by SPU 500. In the preferred 
embodiment, it contains a list of references to shared data 

40 elements (e.g., load modules 1100 and UDEs 1200), private 
data elements (e.g., method data and local stack), and 
swapped process "context" information (e.g., the register set 
for the process when it is not processing). FIG. 14C shows 
an example of a snapshot of SPU RAM 532 storing several 

45 examples of "swap blocks" for a number of different tasks/ 
methods such as a "channel" task, a "control" task, an 
"event" task, a "meter" task, a "budget" task, and a "billing" 
task. Depending on the size of SPU RAM 532, "swap 
blocks" may be swapped out of RAM and stored temporarily 

50 on secondary storage 652 until their execution can be 
continued. Thus, SPE 503 operating in a multi-tasking mode 
may have one or more tasks "sleeping." In the simplest form, 
this involves an active task that is currently processing, and 
another task (e.g., a control task under which the active task 

55 may be running) that is "sleeping" and is "swapped out" of 
active execution space. Kernel/dispatcher 522 may swap out 
tasks at any time. 

Task manager 576 may use Memory Manager 578 to help 
it perform this swapping operation. Tasks may be swapped 

60 out of the secure execution space by reading appropriate 
information from RAM and other storage internal to SPU 
500, for example, and writing a "swap block" to secondary 
storage 652. Kernel 552 may swap a task back into the 
secure execution space by reading the swap block from 

65 secondary storage 652 and writing the appropriate informa- 
tion back into SPU RAM 532. Because secondary storage 
652 is not secure, SPE 503 must encrypt and cryptographi- 
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cally seal (e.g., using a one-way hash function initialized 
with a secret value known only inside the SPU 500) each 
swap block before it writes it to secondary storage. The SPE 
503 must decrypt and verify the cryptographic seal for each 
swap block read from secondary storage 652 before the 5 
swap block can be returned to the secure execution space for 
further execution. 

Loading a "swap block*' into SPU memory may require 
one or more "paging operations" to possibly first save, and 
then flush, any "dirty pages" (i.e., pages changed by SPE 10 
503) associated with the previously loaded swap blocks, and 
to load all required pages for the new swap block context. 

Kernel/dispatcher 522 preferably manages the "swap 
blocks" using service interrupt queues 588. These service 
interrupt queues 588 allow kernel/dispatcher 552 to track 15 
tasks (swap blocks) and their status (running, "swapped 
out," or "asleep"). The kernel/dispatcher 552 in the preferred 
embodiment may maintain the following service interrupt 
queues 588 to help it manage the "swap blocks": 

RUN queue 20 

SWAP queue 

SLEEP queue. 

Those tasks that are completely loaded in the execution 
space and are waiting for and/or using execution cycles from 
microprocessor 502 are in the RUN queue. Those tasks that 25 
are "swapped" out (e.g., because they are waiting for other 
swappable components to be loaded) are referenced in the 
SWAP queue. Those tasks that are "asleep" (e.g., because 
they are "blocked" on some resource other than processor 
cycles or are not needed at the moment) are referenced in the 30 
SLEEP queue. Kernel/dispatcher task manager 576 may, for 
example, transition tasks between the RUN and SWAP 
queues based upon a "round-robin" scheduling algorithm 
that selects the next task waiting for service, swaps in any 
pieces that need to be paged in, and executes the task. 35 
Kernel/dispatcher 552 task manager 576 may transition 
tasks between the SLEEP queue and the "awake" (i.e., RUN 
or SWAP) queues as needed. 

When two or more tasks try to write to the same data 
structure in a multi -tasking environment, a situation exists 40 
that may result in "deadly embrace" or "task starvation." A 
"multi-threaded" tasking arrangement may be used to pre- 
vent "deadly embrace" or "task starvation" from happening. 
The preferred embodiment kernel/dispatcher 552 may sup- 
port "single threaded" or "multi- threaded" tasking. 45 

In single threaded applications, the kernel/dispatcher 552 
"locks" individual data structures as they are loaded. Once 
locked, no other SPE 503 task may load them and will 
"block" waiting for the data structure to become available. 
Using a single threaded SPE 503 may, as a practical matter, 50 
limit the ability of outside vendors to create load modules 
1100 since there can be no assurance that they will not cause 
a "deadly embrace" with other VDE processes about which 
outside vendors may know little or nothing. Moreover, the 
context swapping of a partially updated record might destroy 55 
the integrity of the system, permit unmetered use, and/or 
lead to deadlock. In addition, such "locking" imposes a 
potentially indeterminate delay into a typically time critical 
process, may limit SPE 503 throughput, and may increase 
overhead. 60 

This issue notwithstanding, there are other significant 
processing issues related to building single-threaded ver- 
sions of SPE 503 that may limit its usefulness or capabilities 
under some circumstances. For example, multiple concur- 
rently executing tasks may not be able to process using the 65 
same often-needed data structure in a single-threaded SPE 
503. This may effectively limit the number of concurrent 
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tasks to one. Additionally, single-threadedness may elimi- 
nate the capability of producing accurate summary budgets 
based on a number of concurrent tasks since multiple 
concurrent tasks may not be able to effectively share the 
same summary budget data structure. Single-threadedness 
may also eliminate the capability to support audit processing 
concurrently with other processing. For example, real-time 
feed processing might have to be shut down in order to audit 
budgets and meters associated with the monitoring process. 

One way to provide a more workable "single-threaded" 
capability is for kernel/dispatcher 552 to use virtual page 
handling algorithms to track "dirty pages" as data areas are 
written to. The "dirty pages" can be swapped in and out with 
the task swap block as part of local data associated with the 
swap block. When a task exits, the "dirty pages" can be 
merged with the current data structure (possibly updated by 
another task for SPU 500) using a three-way merge algo- 
rithm (i.e., merging the original data structure, the current 
data structure, and the "dirty pages" to form a new current 
data structure). During the update process, the data structure 
can be locked as the pages are compared and swapped. Even 
though this virtual paging solution might be workable for 
allowing single threading in some applications, the vendor 
limitations mentioned above may limit the use of such single 
threaded implementations in some cases to dedicated hard- 
ware. Any implementation that supports multiple users (e.g., 
"smart home" set tops, many desk tops and certain PDA 
applications, etc.) may hit limitations of a single threaded 
device in certain circumstances. 

It is preferable when these limitations are unacceptable to 
use a full "multi-threaded" data structure write capabilities. 
For example, a type of "two-phase commit" processing of 
the type used by database vendors may be used to allow data 
structure sharing between processes. To implement this 
"two-phase commit" process, each swap block may contain 
page addresses for additional memory blocks that will be 
used to store changed information. A change page is a local 
copy of a piece of a data element that has been written by an 
SPE process. The changed page(s) references associated 
with a specific data structure are stored locally to the swap 
block in the preferred embodiment. 

For example, SPE 503 may support two (change pages) 
per data structure. This limit is easily alterable by changing 
the size of the swap block structure and allowing the update 
algorithm to process all of the changed pages. The "commit" 
process can be invoked when a swap block that references 
changed pages is about to be discarded. The commit process 
takes the original data element that was originally loaded 
(e.g., UDEo), the current data element (e.g., UDEJ and the 
changed pages, and merges them to create a new copy of the 
data element (e.g., UDE„ +1 ). Differences can be resolved by 
the DTD interpreter 590 using a DTD for the data element. 
The original data element is discarded (e.g., as determined 
by its DTD use count) if no other swap block references it. 

B. Kernel/Dispatcher Memory Management 

Memory manager 578 and virtual memory manager 580 
in the preferred embodiment manage ROM 532 and RAM 
534 memory within SPU 500 in the preferred embodiment. 
Virtual memory manager 580 provides a fully "virtual" 
memory system to increase the amount of "virtual" RAM 
available in the SPE secure execution space beyond the 
amount of physical RAM 534a provided by SPU 500. 
Memory manager 578 manages the memory in the secure 
execution space, controlling how it is accessed, allocated 
and deallocated. SPU MMU 540, if present, supports virtual 
memory manager 580 and memory manager 578 in the 
preferred embodiment. In some "minimal" configurations of 
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SPU 500 there may be no virtual memory capability and all agement may be slightly more complex since the "burn 

memory management functions will be handled by memory count" for each EEPROM page may need to be retained, 

manager 578. Memory management can also be used to help SPU EEPROM 532B may need to be protected from all 

enforce the security provided by SPE 503. In some classes uncontrolled writes to conserve the limited writable lifetime 

of SPUs 500, for example, the kernel memory manager 578 5 of certain types of this memory. Furthermore, EEPROM 

may use hardware memory management unit (MMU) 540 to P a S es mav 10 some cases not be ^ c same size as memory 

provide page level protection within the SPU 500. Such a management address pages. 

hardware-based memory management system provides an SPU NVRAM SMb is preferably battery backed RAM 
effective mechanism for protecting VDE component assem- mat has a f cw access restrictions. Memory manager 578 can 
blies 690 from compromise by "rogue" load modules. 10 ensure control structures that must be located in NVRAM 
In addition, memory management provided by memory 534 & not relocated during "garbage collection" pro- 
manager 578 operating at least in part based on hardware- cesses. As discussed above, memory manager 578 (and 
based MMU 540 may securely implement and enforce a MMU 540 if present) may protect NVRAM 534/? and RAM 
memory architecture providing multiple protection domains. 534a at a page level to prevent tampering by other processes. 
In such an architecture, memory is divided into a plurality of 15 Virtual memory manager 580 provides paging for pro- 
domains that are largely isolated from each other and share grams and data between SPU external memory and SPU 
only specific memory areas under the control of the memory internal RAM 534a. It is likely that data structures and 
manager 578. An executing process cannot access memory executable processes will exceed the limits of any SPU 500 
outside its domain and can only communicate with other internal memory. For example, PERCs 808 and other fun- 
processes through services provided by and mediated by 20 damental control structures may be fairly large, and "bit map 
privileged kernel/dispatcher software 552 within the SPU meters" may be, or become, very large. This eventuality may 
500. Such an architecture is more secure if it is enforced at bc addressed in two ways: 
least in part by hardware within MMU 540 that cannot be (1) subdividing load modules 1100; and 
modified by any software-based process executing within (2) supporting virtual paging. 

SPU 500. 25 Load modules 1100 can be "subdivided" in that in many 

In the preferred embodiment, access to services imple- instances they can be broken up into separate components 

mented in the ROM 532 and to physical resources such as only a subset of which must be loaded for execution. Load 

NVRAM SMb and RTC 528 are mediated by the combina- modules 1100 are the smallest pagable executable element in 

tion of privileged kernel/dispatcher software 552 and hard- this example. Such load modules 1100 can be broken up into 

ware within MMU 540. ROM 532 and RTC 528 requests are 30 separate components (e.g., executable code and plural data 

privileged in order to protect access to critical system description blocks), only one of which must be loaded for 

component routines (e.g., RTC 528). simple load modules to execute. This structure permits a 

Memory manager 578 is responsible for allocating and load module 1100 to initially load only the executable code 

deallocating memory; supervising sharing of memory and to load the data description blocks into the other system 

resources between processes; and enforcing memory access/ 35 pages on a demand basis. Many load modules 1100 that have 

use restriction. The SPE kernel/dispatcher memory manager executable sections that are too large to fit into SPU 500 can 

578 typically initially allocates all memory to kernel 552, be restructured into two or more smaller independent load 

and may be configured to permit only process-level access modules. Large load modules may be manually "split" into 

to pages as they are loaded by a specific process. In one multiple load modules that are "chained" together using 

example SPE operating system configuration, memory man- 40 explicit load module references. 

ager 578 allocates memory using a simplified allocation Although "demand paging" can be used to relax some of 
mechanism. A list of each memory page accessible in SPE these restrictions, the preferred embodiment uses virtual 
503 may be represented using a bit map allocation vector, for paging to manage large data structures and executables. 
example. In a memory block, a group of contiguous memory Virtual Memory Manager 580 "swaps" information (e.g., 
pages may start at a specific page number. The size of the 45 executable code and/or data structures) into and out of SPU 
block is measured by the number of memory pages it spans. RAM 534a, and provides other related virtual memory 
Memory allocation may be recorded by setting/clearing the management services to allow a full virtual memory man- 
appropriate bits in the allocation vector. agement capability. Virtual memory management may be 

To assist in memory management functions, a "dope important to allow limited resource SPU 500 configurations 

vector" may be prepended to a memory block. The "dope 50 to execute large and/or multiple tasks, 

vector*' may contain information allowing memory manager C. SPE Load Module Execution Manager 568 

578 to manage that memory block. In its simplest form, a The SPE (HPE) load module execution manager 

memory block may be structured as a "dope vector" fol- ("LMEM") 568 loads executables into the memory managed 

lowed by the actual memory area of the block. This "dope by memory manager 578 and executes them. LMEM 568 

vector" may include the block number, support for dynamic 55 provides mechanisms for tracking load modules that are 

paging of data elements, and a marker to detect memory currently loaded inside the protected execution environment, 

overwrites. Memory manager 578 may track memory blocks LMEM 568 also provides access to basic load modules and 

by their block number and convert the block number to an code fragments stored within, and thus always available to, 

address before use. All accesses to the memory area can be SPE 503. LMEM 568 may be called, for example, by load 

automatically offset by the size of the "dope vector" during 60 modules 1100 that want to execute other load modules, 

conversion from a block memory to a physical address. In the preferred embodiment, the load module execution 

"Dope vectors" can also be used by virtual memory manager manager 568 includes a load module executor ("program 

580 to help manage virtual memory. loader") 570, one or more internal load modules 572, and 

The ROM 532 memory management task performed by library routines 574. Load module executor 570 loads 
memory manager 578 is relatively simple in the preferred 65 executables into memory (e.g., after receiving a memory 
embodiment. All ROM 532 pages may be flagged as "read allocation from memory manager 578) for execution. Inter- 
only" and as "non-pagable." EEPROM 532B memory man- nal load module library 572 may provide a set of commonly 
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used basic load modules 1100 (stored in ROM 532 or 
NVRAM 534£>, for example). Library routines 574 may 
provide a set of commonly used code fragments/routines 
(e.g., bootstrap routines) for execution by SPE 503. 

library routines 574 may provide a standard set of library 5 
functions in ROM 532. A standard list of such library 
functions along with their entry points and parameters may 
be used. Load modules 1100 may call these routines (e.g., 
using an interrupt reserved for this purpose). Library calls 
may reduce the size of load modules by moving commonly 
used code into a central location and permitting a higher 
degree of code reuse. All load modules 1100 for use by SPE 
503 are preferably referenced by a load module execution 
manager 568 that maintains and scans a list of available load 
modules and selects the appropriate load module for execu- 
tion. If the load module is not present within SPE 503, the 15 
task is "slept" and LMEM 568 may request that the load 
module U00 be loaded from secondary storage 562. This 
request may be in the form of an RPC call to secure database 
manager 566 to retrieve the load module and associated data 
structures, and a call to encrypt/decrypt manager 556 to 20 
decrypt the load module before storing it in memory allo- 
cated by memory manager 578. 

In somewhat more detail, the preferred embodiment 
executes a load module 1100 by passing the load module 
execution manager 568 the name (e.g., VDE ID) of the 25 
desired load module 1100. LMEM 568 first searches the list 
of "in memory" and "built-in" load modules 572. If it cannot 
find the desired load module 1100 in the list, it requests a 
copy from the secure database 610 by issuing an RPC 
request that may be handled by ROS secure database man- 30 
ager 744 shown in FIG. 12. Load module execution manager 
568 may then request memory manager 578 to allocate a 
memory page to store the load module 1100. The load 
module execution manager 568 may copy the load module 
into that memory page, and queue the page for decryption 35 
and security checks by encrypt/decrypt manager 556 and 
key and tag manager 558. Once the page is decrypted and 
checked, the load module execution manager 568 checks the 
validation tag and inserts the load module into the list of 
paged in modules and returns the page address to the caller. 40 
The caller may then call the load module 1100 directly or 
allow the load module execution module 570 to make the 
call for it. 

FIG. 15a shows a detailed example of a possible format 
for a channel header 596 and a channel 594 containing 45 
channel detail records 594(1), 594(2), . . . 594(N). Channel 
header 596 may include a channel ID field 597(1), a user ID 
field 597(2), an object ID field 597(3), a field containing a 
reference or other identification to a "right" (i.e., a collection 
of events supported by methods referenced in a PERC 808 50 
and/or "user rights table" 464) 597(4), an event queue 
597(5), and one or more fields 598 that cross-reference 
particular event codes with channel detail records ("CDRs"). 
Channel header 596 may also include a "jump" or reference 
table 599 that permits addressing of elements within an 55 
associated component assembly or assemblies 690. Each 
CDR 594(1), . . . 594(N) corresponds to a specific event 
(event code) to which channel 594 may respond. In the 
preferred embodiment, these CDRs may include explicitly 
and/or by reference each method core 1000' (or fragment 60 
thereof), load module 1100 and data stmcture(s), (e.g., URT, 
UDE 1200 and/or MDE 1202) needed to process the corre- 
sponding event. In the preferred embodiment, one or more 
of the CDRs (e.g., 594(1)) may reference a control method 
and a URT 464 as a data structure. 65 

FIG. 156 shows an example of program control steps 
performed by SPE 503 to "open" a channel 594 in the 
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preferred embodiment In the preferred embodiment, a chan- 
nel 594 provides event processing for a particular VDE 
object 300, a particular authorized user, and a particular 
"right" (i.e., type of event). These three parameters may be 
passed to SPE 503. Part of SPE kernel/dispatcher 552 
executing within a "channel 0" constructed by low level 
services 582 during a "bootstrap" routine may respond 
initially to this "open channel" event by allocating an 
available channel supported by the processing resources of 
SPE 503 (block 1125). This "channel 0" "open channel" task 
may then issue a series of requests to secure database 
manager 566 to obtain the "blueprint" for constructing one 
or more component assemblies 690 to be associated with 
channel 594 (block 1127). In the preferred embodiment, this 
"blueprint" may comprise a PERC 808 and/or URT 464. In 
may be obtained by using the "Object, User, Right" param- 
eters passed to the "open channel'" routine to "chain" 
together object registration table 460 records, user/object 
table 462 records, URT 464 records, and PERC 808 records. 
This "open channel" task may preferably place calls to key 
and tag manager 558 to validate and correlate the tags 
associated with these various records to ensure that they are 
authentic and match. The preferred embodiment process 
then may write appropriate information to channel header 
596 (block 1129). Such information may include, for 
example, User ID, Object ID, and a reference to the "right" 
that the channel will process. The preferred embodiment 
process may next use the "blueprint" to access (e.g, the 
secure database manager 566 and/or from load module 
execution manager library(ies) 568) the appropriate "control 
method" that may be used to, in effect, supervise execution 
of all of the other methods 1000 within the channel 594 
(block 1131). The process may next "bind" this control 
method to the channel (block 1133), which step may include 
binding information from a URT 464 into the channel as a 
data structure for the control method. The process may then 
pass an "initialization" event into channel 594 (block 1135). 
This "initialization" event may be created by the channel 
services manager 562, the process that issued the original 
call requesting a service being fulfilled by the channel being 
built, or the control method just bound to the channel could 
itself possibly generate an initialization event which it would 
in effect pass to itself. 

In response to this "initialization" event, the control 
method may construct the channel detail records 594(1), . . 
. 594(N) used to handle further events other than the 
"initialization" event. The control method executing 
"within" the channel may access the various components it 
needs to construct associated component assemblies 690 
based on the "blueprint" accessed at step 1127 (block 1137). 
Each of these components is bound to the channel 594 
(block 1139) by constructing an associated channel detail 
record specifying the method core(s) 1000', load module(s) 
1100, and associated data structure(s) (e.g., UDE(s) 1200 
and/or MDE(s) 1202) needed to respond to the event. The 
number of channel detail records will depend on the number 
of events that can be serviced by the "right," as specified by 
the "blueprint" (i.e., URT 464). During this process, the 
control method will construct "swap blocks" to, in effect, set 
up all required tasks and obtain necessary memory alloca- 
tions from kernel 562. The control method will, as 
necessary, issue calls to secure database manager 566 to 
retrieve necessary components from secure database 610, 
issue calls to encrypt/decrypt manager 556 to decrypt 
retrieved encrypted information, and issue calls to key and 
tag manager 558 to ensure that all retrieved components are 
validated. Each of the various component assemblies 690 so 
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constructed are "bound" to the channel through the channel 
header event code/pointer records 598 and by constructing 
appropriate swap blocks referenced by channel detail 
records 594(1), . . . 594(N). When this process is complete, 
the channel 594 ha s be en completely constructed and is 
ready to respond to further events. As a last step, the FIG. 
lSb process may, if desired, deallocate the "initialization" 
event task in order to free up resources. 

Once a channel 594 ha s been constructed in this fashion, 
it will respond to event s as they arrive. Channel services 
manager 562 is responsible for dispatching events to channel 
594. Each time a new event arrives (e.g., via an RPC call), 
channel services manager 562 examines the event to deter- 
mine whether a channel already exists that is capable of 
processing it. If a channel does exist, then the channel 
services manager 562 passes the event to that channel. To 
process the event, it may be necessary for task manager 576 
to "swap in" certain "swappable blocks" defined by the 
channel detail records as active tasks. In this way, executable 
component assemblies 690 formed during the channel open 
process shown in FIG. 15b are placed into active secure 
execution space, the particular component assembly that is 
activated being selected in response to the received event 
code. The activated task will then perform its desired 
function in response to the event. 

To destroy a channel, the various swap blocks defined by 
the channel detail records are destroyed, the identification 
information in the channel header 596 is wiped clean, and 
the channel is made available for re- allocation by the 
"channel 0" "open channel" task. 

D. SPE Interrupt Handlers 584 

As shown in FIG. 13, kernel/dispatcher 552 also provides 
internal interrupt handler(s) 584. These help to manage the 
resources of SPU 500. SPU 500 preferably executes in either 
"interrupt" or "polling" mode for all significant components. 
In polling mode, kernel/dispatcher 552 may poll each of the 
sections/circuits within SPU 500 and emulate an interrupt 
for them. The following interrupts are preferably supported 
by SPU 500 in the preferred embodiment: 

"tick" of RTC 528 

interrupt from bus interface 530 

power fail interrupt 

watchdog timer interrupt 

interrupt from encrypt/decrypt engine 522 

memory interrupt (e.g., from MMU 540). 

When an interrupt occurs, an interrupt controller within 
microprocessor 520 may cause the microprocessor to begin 
executing an appropriate interrupt handler. An interrupt 
handler is a piece of software/firmware provided by kernel/ 
dispatcher 552 that allows microprocessor 520 to perform 
particular functions upon the occurrence of an interrupt. The 
interrupts may be "vectored" so that different interrupt 
sources may effectively cause different interrupt handlers to 
be executed. 

A "timer tick" interrupt is generated when the real-time 
RTC 528 "pulses." The timer tick interrupt is processed by 
a timer tick interrupt handler to calculate internal device 
date/time and to generate timer events for channel process- 
ing. 

The bus interface unit 530 may generate a series of 
interrupts. In the preferred embodiment, bus interface 530, 
modeled after a US ART, generates interrupts for various 
conditions (e.g., "receive buffer full," "transmitter buffer 
empty," and "status word change"). Kernel/dispatcher 552 
services the transmitter buffer empty interrupt by sending 
the next character from the transmit queue to the bus 
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interface 530. Kernel/dispatcher interrupt handler 584 may 
service the received buffer full interrupt by reading a 
character, appending it to the current buffer, and processing 
the buffer based on the state of the service engine for the bus 

5 interface 530. Kernel/dispatcher 552 preferably processes a 
status word change interrupt and addresses the appropriate 
send/receive buffers accordingly. 

SPU 500 generates a power fail interrupt when it detects 
an imminent power fail condition. This may require imme- 
diate action to prevent loss of information. For example, in 
the preferred embodiment, a power fail interrupt moves all 
recently written information (i.e., "dirty pages") into non- 
volatile NVRAM 534£>, marks all swap blocks as "swapped 
out," and sets the appropriate power fail flag to facilitate 
recovery processing. Kernel/dispatcher 552 may then peri- 

15 odically poll the "power fail bit" in a status word until the 
data is cleared or the power is removed completely. 

SPU 500 in the example includes a conventional watch- 
dog timer that generates watchdog timer interrupts on a 
regular basis. A watchdog timer interrupt handler performs 

20 internal device checks to ensure that tampering is not 
occurring. The internal clocks of the watchdog timer and 
RTC 528 are compared to ensure SPU 500 is not being 
paused or probed, and other internal checks on the operation 
of SPU 500 are made to detect tampering, 

25 The encryption/decryption engine 522 generates an inter- 
rupt when a block of data has been processed. The kernel 
interrupt handler 584 adjusts the processing status of the 
block being encrypted or decrypted, and passes the block to 
the next stage of processing. The next block scheduled for 

30 the encryption service then has its key moved into the 
encrypt/decrypt engine 522, and the next cryptographic 
process started. 

A memory management unit 540 interrupt is generated 
when a task attempts to access memory outside the areas 

35 assigned to it. A memory management interrupt handler 
traps the request, and takes the necessary action (e.g., by 
initiating a control transfer to memory manager 578 and/or 
virtual memory manager 580). Generally, the task will be 
failed, a page fault exception will be generated, or appro- 

40 priate virtual memory page(s) will be paged in. 

E. Kernel/Dispatcher Low Level Services 582 

Low level services 582 in the preferred embodiment 
provide "low level" functions. These functions in the pre- 
ferred embodiment may include, for example, power-on 

45 initialization, device POST, and failure recovery routines. 
Low level services 582 may also in the preferred embodi- 
ment provide (either by themselves or in combination with 
authentication manager/service communications manager 
564) download response-challenge and authentication com- 

50 munication protocols, and may provide for certain low level 
management of SPU 500 memory devices such as EEPROM 
and FLASH memory (either alone or in combination with 
memory manager 578 and/or virtual memory manager 580). 

F. Kernel/Dispatcher BIU handier 586 

55 BIU handler 586 in the preferred embodiment manages 
the bus interface unit 530 (if present). It may, for example, 
maintain read and write buffers for the BIU 530, provide 
BIU startup initialization, etc. 

G. Kernel/Dispatcher DTD Interpreter 590 

60 DTD interpreter 590 in the preferred embodiment handles 
data formatting issues. For example, the DTD interpreter 
590 may automatically open data structures such as UDEs 
1200 based on formatting instructions contained within 
DTDs. 

65 The SPE kernel/dispatcher 552 discussed above supports 
all of the other services provided by SPE 503. Those other 
services are discussed below. 
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II. SPU Channel Services Manager 562 

"Channels" are the basic task processing mechanism of 
SPE 503 (HPE 655) in the preferred embodiment. ROS 602 
provides an event-driven interface for "methods." A "chan- 
nel" allows component assemblies 690 to service events. A 
"channel" is a conduit for passing "events" from services 
supported by SPE 503 (HPE 655) to the various methods and 
load modules that have been specified to process these 
events, and also supports the assembly of component assem- 
blies 690 and interaction between component assemblies. In 
more detail, "channel" 594 is a data structure maintained by 
channel manager 593 that "binds" together one or more load 
modules 1100 and data structures (e.g., UDEs 1200 and/or 
MDEs 1202) into a component assembly 690. Channel 
services manager 562 causes load module execution man- 
ager 569 to load the component assembly 690 for execution, 
and may also be responsible for passing events into the 
channel 594 for response by a component assembly 690. In 
the preferred embodiment, event processing is handled as a 
message to the channel service manager 562. 

FIG. 15 is a diagram showing how the preferred embodi- 
ment channel services manager 562 constructs a "channel" 
594, and also shows the relationship between the channel 
and component assemblies 690, Briefly, the SPE channel 
manager 562 establishes a "channel" 594 and an associated 
"channel header" 596. The channel 594 and its header 596 
comprise a data structure that "binds" or references elements 
of one or more component assemblies 690. Thus, the chan- 
nel 594 is the mechanism in the preferred embodiment that 
collects together or assembles the elements shown in FIG. 
HE into a component assembly 690 that may be used for 
event processing. 

The channel 594 is set up by the channel services manager 
562 in response to the occurrence of an event. Once the 
channel is created, the channel services manager 562 may 
issue function calls to load module execution manager 568 
based on the channel 594. The load module execution 
manager 568 loads the load modules 1100 referenced by a 
channel 594, and requests execution services by the kernel/ 
dispatcher task manager 576. The kernel/dispatcher 552 
treats the event processing request as a task, and executes it 
by executing the code within the load modules 1100 refer- 
enced by the channel. 

The channel services manager 562 may be passed an 
identification of the event (e.g., the "event code"). The 
channel services manager 562 parses one or more method 
cores 1000' that are part of the component assembly(ies) 690 
the channel services manager is to assemble. It performs this 
parsing to determine which method(s) and data structure^) 
arc invoked by the type of event. Channel manager 562 then 
issues calls (e.g., to secure database manager 566) to obtain 
the methods and data structure(s) needed to build the com- 
ponent assembly 690. These called-for method(s) and data 
structure^) (e.g., load modules 1100, UDEs 1200 and/or 
MDEs 1202) are each decrypted using encrypt/decrypt man- 
ager 556 (if necessary), and are then each validated using 
key and tag manager 558. Channel manager 562 constructs 
any necessary "jump table" references to, in effect, "link" or 
"bind" the elements into a single cohesive executable so the 
load module(s) can reference data structures and any other 
load module(s) in the component assembly. Channel man- 
ager 562 may then issue calls to LMEM 568 to load the 
executable as an active task. 

FIG. 15 shows that a channel 594 may reference another 
channel. An arbitrary number of channels 594 may be 
created by channel manager 594 to interact with one another. 

"Channel header** 596 in the preferred embodiment is (or 
references) the data structure(s) and associated control 
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program(s) that queues events from channel event sources, 
processes these events, and releases the appropriate tasks 
specified in the "channel detail record" for processing. A 
"channel detail record" in the preferred embodiment links an 
event to a "swap block" (i.e., task) associated with that 
event. The "swap block" may reference one or more load 
modules 1100, UDEs 1200 and private data areas required to 
properly process the event. One swap block and a corre- 
sponding channel detail item is created for each different 
event the channel can respond to. 

In the preferred embodiment, Channel Services Manager 
562 may support the following (internal) calls to support the 
creation and maintenance of channels 562: 
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Call Name 



Source Description 



"Write Event" Write Writes an event to the channel for 
response by the channel. The 
W ri te Event call thus permit the 
caller to insert an event into the 
event queue associated with the 
channel. The event will be 
processed in turn by the channel 
594. 

"Bind Item" Ioctl Binds an item to a channel with 

the appropriate processing 
algorithm. The Bind Item call 
permits the caller to bind a VDE 
item ID to a channel (e.g., to create 
one or more swap blocks associated 
with a channel). This call may 
manipulate the contents of 
individual swap blocks. 

"Unbind Item" Ioctl Unbinds an item from a channel 

with the appropriate processing 
algorithm. The Unbind Item call 
permits the caller to break the 
binding of an item to a swap block. 
This call may manipulate the 
contents of individual swap blocks. 



SPE RPC Manager 550 

As described in connection with FIG. 12, the architecture 
of ROS 602 is based on remote procedure calls in the 
preferred embodiment. ROS 602 includes an RPC Manager 
732 that passes RPC calls between services each of which 
present an RPC service interface ("RSI") to the RPC man- 
ager. In the preferred embodiment, SPE 503 (HPE 655) is 
also built around the same RPC concept. The SPE 503 (HPE 
655) may include a number of internal modular service 
providers each presenting an RSI to an RPC manager 550 
internal to the SPE (HPE). These internal service providers 
may communicate with each other and/or with ROS RPC 
manager 732 (and thus, with any other service provided by 
ROS 602 and with external services), using RPC service 
requests. 

RPC manager 550 within SPE 503 (HPE 655) is not the 
same as RPC manager 732 shown in FIG. 12, but it performs 
a similar function within the SPE (HPE): it receives RPC 
requests and passes them to the RSI presented by the service 
that is to fulfill the request. In the preferred embodiment, 
requests are passed between ROS RPC manager 732 and the 
outside world (i.e., SPE device driver 736) via the SPE 
(HPE) Kernel/Dispatcher 552. Kernel/Dispatcher 552 may 
be able to service certain RPC requests itself, but in general 
it passes received requests to RPC manager 550 for routing 
to the appropriate service internal to the SPE (HPE). In an 
alternate embodiment, requests may be passed directly 
between the HPE, SPE, API, Notification interface, and 
other external services instead of routing them through the 
ROS RPC manager 732. The decision on which embodiment 
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to use is part of the scalability of the system; some embodi- 
ments are more efficient than others under various traffic 
loads and system configurations. Responses by the services 
(and additional service requests they may themselves 
generate) are provided to RPC Manager 550 for routing to 5 
other service(s) internal or external to SPE 503 (HPE 655). 

SPE RPC Manager 550 and its integrated service manager 
uses two tables to dispatch remote procedure calls: an RPC 
services table, and an optional RPC dispatch table. The RPC 10 
services table describes where requests for specific services 
are to be routed for processing. In the preferred embodiment, 
this table is constructed in SPU RAM 534a or NVRAM 
534Z?, and lists each RPC service "registered" within SPU 
500. Each row of the RPC services table contains a service 15 
ID, its location and address, and a control byte. In simple 
implementations, the control byte indicates only that the 
service is provided internally or externally. In more complex 
implementations, the control byte can indicate an instance of 20 
the service (e.g., each service may have multiple "instances" 
in a multi-tasking environment). ROS RPC manager 732 
and SPE 503 may have symmetric copies of the RPC 
services table in the preferred embodiment. If an RPC 
service is not found in the RPC services table, SPE 503 may 
either reject it or pass it to ROS RPC manager 732 for 
service. 

The SPE RPC manager 550 accepts the request from the 
RPC service table and processes that request in accordance 
with the internal priorities associated with the specific 
service. In SPE 503, the RPC service table is extended by an 
RPC dispatch table. The preferred embodiment RPC dis- 
patch table is organized as a list of Load Module references 
for each RPC service supported internally by SPE 503. Each 
row in the table contains a load module ID that services the 
call, a control byte that indicates whether the call can be 
made from an external caller, and whether the load module 
needed to service the call is permanently resident in SPU 
500. The RPC dispatch table may be constructed in SPU 
ROM 532 (or EEPROM) when SPU firmware 508 is loaded 
into the SPU 500. If the RPC dispatch table is in EEPROM, 
it flexibly allows for updates to the services without load 
module location and version control issues. 

In the preferred embodiment, SPE RPC manager 550 first 
references a service request against the RPC service table to 
determine the location of the service manager that may 
service the request, The RPC manager 550 then routes the 
service request to the appropriate service manager for action. 
Service requests are handled by the service manager within 
the SPE 503 using the RPC dispatch table to dispatch the 
request. Once the RPC manager 550 locates the service 
reference in the RPC dispatch table, the load module that 
services the request is called and loaded using the load 
module execution manager 568. The load module execution 
manager 568 passes control to the requested load module 
after performing all required context configuration, or if 
necessary may first issue a request to load it from the 
external management files 610. 

SPU Time Base Manager 554 

The time base manager 554 supports calls that relate to the 
real time clock ("RTC") 528. In the preferred embodiment, 
the time base manager 554 is always loaded and ready to 
respond to time based requests. 

The table below lists examples of basic calls that may be 
supported by the time base manager 554: 
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Call Name 



Description 



Independent requests 

Get Time Returns the time (local, GMT, or ticks). 

Set time Sets the time in the RFC 528. Access to this 

command may be restricted to a VDE 

administrator. 

Adjust time Changes the time in the RTC 528. Access to 

this command may be restricted to a VDE 
administrator. 

Set Time Set GMT/local time conversion and the 

Parameter current and allowable magnitude of user 

adjustments to RTC 528 time. 
Channel Services Manager Requests 

Bind Tune Bind timer services to a channel as an event 

source. 

Unbind Time Unbind timer services from a channel as an 
event source. 

Set Alarm Sets an alarm notification for a specific time. 

The user will be notified by an alarm event at 
the time of the alarm. Parameters to this 
request determine the event, frequency, and 
requested processing for the alarm. 

Clear Alarm Cancels a requested alarm notification. 



SPU Encryption/Decryption Manager 556 
The Encryption/Decryption Manager 556 supports calls 
to the various encryption/decryption techniques supported 
by SPE 503/HPE 655, It may be supported by a hardware- 
based encryption/decryption engine 522 within SPU 500. 
Those encryption/decryption technologies not supported by 
SPU encrypt/decrypt engine 522 may be provided by 
encrypt/decrypt manager 556 in software. The primary bulk 
encryption/decryption load modules preferably are loaded at 
all times, and the load modules necessary for other algo- 
rithms are preferably paged in as needed. Thus, if the 
primary bulk encryption/decryption algorithm is DES, only 
the DES load modules need be permanently resident in the 
RAM 534a of SPE 503/HPE 655. 

The following are examples of RPC calls supported by 
Encrypt/Decrypt Manager 556 in the preferred embodiment: 



Call Name 


Description 


PK Encrypt 


Encrypt a block using a PK (public key) 




algorithm. 


PK Decrypt 


Decrypt a block using a PK algorithm. 


DES 


Encrypt a block using DES. 


Encrypt 




DES 


Decrypt a block using DES. 


Decrypt 




RC-4 


Encrypt a block using the RC-4 (or other bulk 


Encrypt 


encryption) algorithm. 


RC-4 


Decrypt a block using the RC-4 (or other bulk 


Decrypt 


encryption) algorithm. 


Initialize 


Initialize DES instance to be used. 


DES 




Instance 




Initialize 


Initialize RC-4 instance to be used. 


RC-4 




Instance 




Initialize 


Initialize MD5 instance to be used. 


MD5 




Instance 




Process MD5 


Process MD5 block. 


Block 





The call parameters passed may include the key to be 
used; mode (encryption or decryption); any needed Initial- 
ization Vectors; the desired cryptographic operating (e.g., 
type of feedback); the identification of the cryptographic 



03/04/2003, EAST version: 1.03.0002 



5,8! 

127 

instance to be used; and the start address, destination 
address, and length of the block to be encrypted or 
decrypted. 

SPU Key and Tag Manager 558 

The SPU Key and Tag Manager 558 supports calls for key 
storage, key and management file tag look up, key 
convolution, and the generation of random keys, tags, and 
transaction numbers. 

The following table shows an example of a list of SPE/ 
HPE key and tag manager service 558 calls: 



Call Name 


Description 


Key Requests 




Get Key 


Retrieve the requested key. 


Set Key 


Set (store) the specified key. 


Generate Key 


Generate a key (pair) for a specified algorithm. 


Generate Convoluted 


Generate a key using a specified convolution 


Key 


algorithm and algorithm parameter block. 


Get Convolution 


Return the currently set (default) convolution 


Algorithm 


parameters for a specific convolution 




algorithm. 


Set Convolution 


Sets the convolution parameters for a specific 


Algorithm 


convolution algorithm (calling routine must 




provide a tag to read returned contents). 


Tag Requests 




Get Tag 


Get the validation (or other) tag for a specific 




VDE Item ID. 


Set Tag 


Set the validation (oi other) tag for a specific 




VDE Item ID to a known value. 


Calculate Hash Block 


Calculate the "hash block number" for a 


Number 


specific VDE Item ID. 


Set Hash Parameters 


Set the hash parameters and hash algorithm. 




Forces a resynchronization of the hash table. 


Get Hash Parameters 


Retrieve the current hash 




parameters/algorithm. 


Synchronize 


Synchronize the management files and rebuild 


Management Files 


the hash block tables based on information 


found in the tables. Reserved for VDE 




administrator. 



Keys and tags may be securely generated within SPE 503 
(HPE 655) in the preferred embodiment. The key generation 
algorithm is typically specific to each type of encryption 
supported. The generated keys may be checked for crypto- 
graphic weakness before they are used, A request for Key 
and Tag Manager 558 to generate a key, tag and/or trans- 
action number preferably takes a length as its input param- 
eter. It generates a random number (or other appropriate key 
value) of the requested length as its output. 

The key and tag manager 558 may support calls to retrieve 
specific keys from the key storage areas in SPU 500 and any 
keys stored external to the SPU. The basic format of the calls 
is to request keys by key type and key number. Many of the 
keys are periodically updated through contact with the VDE 
administrator, and are kept within SPU 500 in NVRAM 
S34b or EEPROM because these memories are secure, 
updatable and non-volatile. 

SPE 503/HPE 655 may support both Public Key type keys 
and Bulk Encryption type keys. The public key (PK) encryp- 
tion type keys stored by SPU 500 and managed by key and 
tag manager 558 may include, for example, a device public 
key, a device private key, a PK certificate, and a public key 
for the certificate. Generally, public keys and certificates can 
be stored externally in non-secured memory if desired, but 
the device private key and the public key for the certificate 
should only be stored internally in an SPU 500 EEPROM or 
NVRAM 5346. Some of the types of bulk encryption keys 
used by the SPU 500 may include, for example, general- 
purpose bulk encryption keys, administrative object private 
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header keys, stationary object private header keys, traveling 
object private header keys, download/initialization keys, 
backup keys, trail keys, and management file keys. 
As discussed above, preferred embodiment Key and Tag 

5 Manager 558 supports requests to adjust or convolute keys 
to make new keys that are produced in a deterministic way 
dependent on site and/or time, for example. Key convolution 
is an algorithmic process that acts on a key and some set of 
input parameters) to yield a new key. It can be used, for 
example, to increase the number of keys available for use 
without incurring additional key storage space. It may also 
be used, for example, as a process to "age" keys by incor- 
porating the value of real-time RTC 528 as parameters. It 
can be used to make keys site specific by incorporating 
aspects of the site ID as parameters. 

15 Key and Tag Manager 558 also provides services relating 
to tag generation and management. In the preferred 
embodiment, transaction and access tags are preferably 
stored by SPE 503 (HPE 655) in protected memory (e.g., 
within the NVRAM 534b of SPU 500). These tags may be 

20 generated by key and tag manager 558. They are used to, for 
example, check access rights to, validate and correlate data 
elements. For example, they may be used to ensure compo- 
nents of the secured data structures are not tampered with 
outside of the SPU 500. Key and tag manager 558 may also 

25 support a trail transaction tag and a communications trans- 
action tag. 
SPU Summary Services Manager 560 
SPE 503 maintains an audit trail in reprogrammable 
non-volatile memory within the SPU 500 and/or in secure 

30 database 610. This audit trail may consist of an audit 
summary of budget activity for financial purposes, and a 
security summary of SPU use. When a request is made to the 
SPU, it logs the request as having occurred and then notes 
whether the request succeeded or failed. All successful 

35 requests may be summed and stored by type in the SPU 500. 
Failure information, including the elements listed below, 
may be saved along with details of the failure: 



40 Control Information Retained in 

an SPE on Access Failures 

Object ID 
User ID 
Type of failure 
Time of failure 



This information may be analyzed to detect cracking 
attempts or to determine patterns of usage outside expected 
(and budgeted) norms. The audit trail histories in the SPU 

50 500 may be retained until the audit is reported to the 
appropriate parties. This will allow both legitimate failure 
analysis and attempts to cryptoanalyze the SPU to be noted. 

Summary services manager 560 may store and maintain 
this internal summary audit information. This audit infor- 

55 mation can be used to check for security breaches or other 
aspects of the operation of SPE 503. The event summaries 
may be maintained, analyzed and used by SPE 503 (HPE 
655) or a VDE administrator to determine and potentially 
limit abuse of electronic appliance 600. In the preferred 

60 embodiment, such parameters may be stored in secure 
memory (e.g., within the NVRAM 5346 of SPU 500). 

There are two basic structures for which summary ser- 
vices are used in the preferred embodiment. One (the "event 
summary data structure") is VDE administrator specific and 

65 keeps track of events. The event summary structure may be 
maintained and audited during periodic contact with VDE 
administrators. The other is used by VDE administrators 
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and/or distributors for overall budget. A VDE administrator 
may register for event summaries and an overall budget 
summary at the time an electronic appliance 600 is initial- 
ized. The overall budget summary may be reported to and 
used by a VDE administrator in determining distribution of 
consumed budget (for example) in the case of corruption of 
secure management files 610. Participants that receive 
appropriate permissions can register their processes (e.g., 
specific budgets) with summary services manager 560, 
which may then reserve protected memory space (e.g., 
within NVRAM 534b) and keep desired use and/or access 
parameters. Access to and modification of each summary 
can be controlled by its own access tag. 

The following table shows an example of a list of PPE 
summary service manager 560 service calls: 



Call Name 



Description 



Create summary 
info 

Get value 



Set value 
Increment 



Destroy 



Create a summary service if the user 
has a "ticket" that permits her to 
request this service. 
Return the current value of the 
summary service. The caller must 
present an appropriate tag (and/or 
"ticket/') to use this request. 
Set the value of a summary service. 
Increment the specified summary 
service(e.g,, a scalar meter summary 
data area). The caller must present 
an appropriate tag (and/or "ticket") to 
use this request 

Destroy the specified summary service 
if the user has a tag and/or "ticket" 
that permits them to request this 
service. 



20 



25 



30 



Event Type 



Successful Initialization completed successfully. 

Events User authentication accepted. 

Communications established. 

Channel loads set for specified values. 

Decryption completed. 

Key information updated. 

New budget created or existing budget 

updated. 

New billing information generated or 

existing billing updated. 

New meter set up or existing meter 

updated. 

New PERC created or existing PERC 
updated. 

New objects registered. 
Administrative objects successfully 
processed. 
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-continued 



Event Type 



10 



15 



Audit processed successfully. 
All other events. 
Failed Events Initialization failed. 

Authentication failed. 

Communication attempt failed. 

Request to load a channel failed. 

Validation attempt unsuccessful. 

Link to subsidiary item failed 

correlation tag match. 

Authorization attempt failed. 

Decryption attempt failed. 

Available budget insufficient to complete 

requested procedure. 

Audit did not occur. 

Administrative object did not process 

correctly. 

Other failed events. 



In the preferred embodiment, the event summary data 35 
structure uses a fixed event number to index into a look up 
table. The look up table contains a value that can be 
configured as a counter or a counter plus limit. Counter 
mode may be used by VDE administrators to determine 
device usage. The limit mode may be used to limit tampering 40 
and attempts to misuse the electronic appliance 600. 
Exceeding a limit will result in SPE 503 (HPE 655) refusing 
to service user requests until it is reset by a VDE adminis- 
trator. Calls to the system wide event summary process may 
preferably be built into all load modules that process the 45 
events that are of interest. 

The following table shows examples of events that may 
be separately metered by the preferred embodiment event 
summary data structure: 



Another, "overall currency budget" summary data struc- 
ture maintained by the preferred embodiment summary 
services manager 560 allows registration of VDE electronic 
appliance 600. The first entry is used for an overall currency 
budget consumed value, and is registered by the VDE 
administrator that first initializes SPE 503 (HPE 655). Cer- 
tain currency consuming load modules and audit load mod- 
ules that complete the auditing process for consumed cur- 
rency budget may call the summary services manager 560 to 
update the currency consumed value. Special authorized 
load modules may have access to the overall currency 
summary, while additional summaries can be registered for 
by individual providers. 

SPE Authentication Manager/Service Communications 
Manager 564 

The Authentication Manager/Service Communications 
Manager 564 supports calls for user password validation and 
"ticket" generation and validation. It may also support 
secure communications between SPE 503 and an external 
node or device (e.g., a VDE administrator or distributor). It 
may support the following examples of authentication- 
related service requests in the preferred embodiment: 



Call Name 



Description 



50 



55 



60 



User Services 



Create User 



Authenticate 
User 



Delete User 
Ticket Services 

Generate 
Ticket 
Authenticate 
Ticket 



Creates a new user and stores Name Services 
Records (NSRs) for use by the Name Services 
Manager 752. 

Authenticates a user for use of the system. 
This request lets the caller authenticate as a 
specific user ID. Group membership is also 
authenticated by this request The 
authentication returns a u ticket" for the user. 
Deletes a user's NSR and related records. 



Generates a "ticket" for use of one or more 
services. 

Authenticates a "ticket." 



Not included in the table above are calls to the secure 
communications service. The secure communications ser- 
vice provided by manager 564 may provide (e.g., in con- 
junction with low-level services manager 582 if desired) 
secure communications based on a public key (or others) 
65 challenge-response protocol. This protocol is discussed in 
further detail elsewhere in this document. Tickets identify 
users with respect to the electronic appliance 600 in the case 
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where the appliance may be used by multiple users. Tickets 
may be requested by and returned to VDE software appli- 
cations through a ticket-granting protocol (e.g., Kerberos), 
VDE components may require tickets to be presented in 
order to authorize particular services. 

SPE Secure Database Manager 566 

Secure database manager 566 retrieves, maintains and 
stores secure database records within secure database 610 on 
memory external to SPE 503. Many of these secure database 
files 610 are in encrypted form. All secure information 
retrieved by secure database manager 566 therefore must be 
decrypted by encrypt/decrypt manager 556 before use. 
Secure information (e.g., records of use) produced by SPE 
503 (HPE 655) which must be stored external to the secure 
execution environment are also encrypted by encrypt/ 
decrypt manager 556 before they are stored via secure 
database manager 566 in a secure database file 610. 

For each VDE item loaded into SPE 503, Secure Database 
manager 566 in the preferred embodiment may search a 
master list for the VDE item ID, and then check the 
corresponding transaction tag against the one in the item to 
ensure that the item provided is the current item. Secure 
Database Manager 566 may maintain list of VDE item ID 
and transaction tags in a "hash structure" that can be paged 
into SPE 503 to quickly locate the appropriate VDE item ID. 
In smaller systems, a look up table approach may be used. 
In either case, the list should be structured as a pagable 
structure that allows VDE item ID to be located quickly. 

Hie "hash based" approach may be used to sort the list 
into "hash buckets" that may then be accessed to provide 
more rapid and efficient location of items in the list. In the 
"hash based" approach, the VDE item IDs are "hashed" 
through a subset of the full item ID and organized as pages 
of the "hashed" table. Each "hashed" page may contain the 
rest of the VDE item ID and current transaction tag for each 
item associated with that page. The "hash" table page 
number may be derived from the components of the VDE 
item ID, such as distribution ID, item ID, site ID, user ID, 
transaction tag, creator ID, type and/or version. The hashing 
algorithm (both the algorithm itself and the parameters to be 
hashed) may be configurable by a VDE administrator on a 
site by site basis to provide optimum hash page use. An 
example of a hash page structure appears below: 



Field 

Hash Page Header 

Distributor ID 

Item ID 

Site ID 

User ID 

Transaction Tag 

Hash Page Entry 

Creator ID 

Item ID 

Type 

Version 

Transaction Tag 



In this example, each hash page may contain all of the 
VDE item IDs and transaction tags for items that have 
identical distributor ID, item ID, and user ID fields (site ID 
will be fixed for a given electronic appliance 600). These 
four pieces of information may thus be used as hash algo- 
rithm parameters. 

The "hash" pages may themselves be frequently updated, 
and should carry transaction tags that are checked each time 
a "hash" page is loaded. The transaction tag may also be 
updated each time a "hash" page is written out. 

As an alternative to the hash-based approach, if the 
number of updatable items is kept small (such as in a 
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dedicated consumer electronic appliance 600), then assign- 
ing each updatable item a unique sequential site record 
number as part of its VDE item ID may allow a look up table 
approach to be used. Only a small number of bytes of 
5 transaction tag are needed per item, and a table transaction 
tag for all frequently updatable items can be kept in pro- 
tected memory such as SPU NVRAM 534fc. 

Random Value Generator Manager 565 

Random Value Generator Manager 565 may generate 
1Q random values. If a hardware -based SPU random value 
generator 542 is present, the Random Value Generator 
Manager 565 may use it to assist in generating random 
values. 

Other SPE RPC Services 592 

Other authorized RPC services may be included in SPU 

15 500 by having them "register" themselves in the RPC 
Services Table and adding their entries to the RPC Dispatch 
Table. For example, one or more component assemblies 690 
may be used to provide additional services as an integral part 
of SPE 503 and its associated operating system. Requests to 

20 services not registered in these tables will be passed out of 
SPE 503 (HPE 655) for external servicing. 
SPE 503 Performance Considerations 
Performance of SPE 503 (HPE 655) is a function of: 
complexity of the component assemblies used 

25 number of simultaneous component assembly operations 
amount of internal SPU memory available 
speed of algorithm for block encryption/decryption 
The complexity of component assembly processes along 
with the number of simultaneous component assembly pro- 

30 cesses is perhaps the primary factor in determining perfor- 
mance. These factors combine to determine the amount of 
code and data and must be resident in SPU 500 at any one 
time (the minimum device size) and thus the number of 
device size "chunks" the processes must be broken down 

35 into. Segmentation inherently increases run time size over 
simpler models. Of course, feature limited versions of SPU 
500 may be implemented using significantly smaller 
amounts of RAM 534. "Aggregate" load modules as 
described above may remove flexibility in configuring VDE 

40 structures and also further limit the ability of participants to 
individually update otherwise separated elements, but may 
result in a smaller minimum device size. A very simple 
metering version of SPU 500 can be constructed to operate 
with minimal device resources. 

45 The amount of RAM 534 internal to SPU 500 has more 
impact on the performance of the SPE 503 than perhaps any 
other aspect of the SPU. The flexible nature of VDE pro- 
cesses allows use of a large number of toad modules, 
methods and user data elements. It is impractical to store 

50 more than a small number of these items in ROM 532 within 
SPU 500. Most of the code and data structures needed to 
support a specific VDE process will need to be dynamically 
loaded into the SPU 500 for the specific VDE process when 
the process is invoked. The operating system within SPU 

55 500 then may page in the necessary VDE items to perform 
the process. The amount of RAM 534 within SPU 500 will 
directly determine how large any single VDE load module 
plus its required data can be, as well as the number of page 
swaps that will be necessary to run a VDE process. The SPU 

60 I/O speed, encryption/decryption speed, and the amount of 
internal memory 532, 534 will directly affect the number of 
page swaps required in the device. Insecure external 
memory may reduce the wait time for swapped pages to be 
loaded into SPU 500, but will still incur substantial 

65 encryption/decryption penalty for each page. 

In order to maintain security, SPE 503 must encrypt and 
cryptographically seal each block being swapped out to a 
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Each electronic appliance 600 may have an instance of a 
secure database 610 that securely maintains the VDE items. 
FIG. 16 shows one example of a secure database 610. The 
secure database 610 shown in this example includes the 
following VDE-protected items; 

one or more PERCs 808; 

methods 1000 (including static and dynamic method 

"cores" 1000, and MDEs 1202); 
Static UDEs 1200a and Dynamic UDEs 12006; and 
load modules 1100. 

Secure database 610 may also include the following 
additional data structures used and maintained for adminis- 
trative purposes: 

an "object registry" 450 that references an object storage 
728 containing one or more VDE objects; 



10 



storage device external to a supporting SPU 500, and must 
similarly decrypt, verify the cryptographic seal for, and 
validate each block as it is swapped into SPU 500. Thus, the 
data movement and encryption/decryption overhead for 
each swap block has a very large impact on SPE perfor- 
mance. 

The performance of an SPU microprocessor 520 may not 
significantly impact the performance of the SPE 503 it 
supports if the processor is not responsible for moving data 
through the encrypt/decrypt engine 522. 

VDE Secure Database 610 

VDE 100 stores separately deliverable VDE elements in 
a secure (e.g., encrypted) database 610 distributed to each 
VDE electronic appliance 610. The database 610 in the 
preferred embodiment may store and/or manage three basic 
classes of VDE items: 15 

VDE objects, 

VDE process elements, and 
VDE data structures. 

The following table lists examples of some of the VDE 
items stored in or managed by information stored in secure 20 
database 610: 





Class 


Brief Description 




Objects 


Content Objects 

Administrative 
Objects 


Provide a container for 
content. 

Provide a container for 
information used to keep 
VDE 100 operating. 


25 




Traveling Objects 


Provide a container for 


30 






content and control 






information. 






Smart Objects 


Provide a container for 
(user-specified) processes 
and data. 




Process 


Method Cores 


Provide a mechanism to 




Elements 


Load Modules 
C'LMs") 
Method Data 


relate events to control 

mechanisms and 

permissions. 

Secure (tamper-resistant) 

executable code. 

Independently deliverable 


35 




Elements ("MDEs") 


data structures used to 


40 






control/customize 






methods. 




Data 


Permissions Records 


Permissions to use 




Structures 


("PERCs") 


objects; '"blueprints" to 
build component 








assemblies. 


45 




User Data Elements 


Basic data structure for 




("UDEs") 


storing information used 
in conjunction with load 
modules. 






Administrative Data 


Used by VDE node to 






Structures 


maintain administrative 


50 






informtion. 



55 



60 



65 
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name service records 452; and 

configuration records 454 (including site configuration 
records 456 and user configuration records 458). 

Secure database 610 in the preferred embodiment does 
not include VDE objects 300, but rather references VDE 
objects stored, for example, on file system 687 and/or in a 
separate object repository 728. Nevertheless, an appropriate 
"starting point" for understanding VDE-protected informa- 
tion may be a discussion of VDE objects 300. 

VDE Objects 300 

VDE 100 provides a media independent container model 
for encapsulating content. FIG. 17 shows an example of a 
"logical" structure or format 800 for an object 300 provided 
by the preferred embodiment. 

The generalized "logical object" structure 800 shown in 
FIG. 17 used by the preferred embodiment supports digital 
content delivery over any currently used media. "Logical 
object" in the preferred embodiment may refer collectively 
to: content; computer software and/or methods used to 
manipulate, record, and/or otherwise control use of said 
content; and permissions, limitations, administrative control 
information and/or requirements applicable to said content, 
and/or said computer software and/or methods. Logical 
objects may or may not be stored, and may or may not be 
present in, or accessible to, any given electronic appliance 
600. The content portion of a logical object may be orga- 
nized as information contained in, not contained in, or 
partially contained in one or more objects. 

Briefly, the FIG. 17 "logical object" structure 800 in the 
preferred embodiment includes a public header 802, private 
header 804, a "private body" 806 containing one or more 
methods 1000, permissions record(s) (PERQ 808 (which 
may include one or more key blocks 810), and one or more 
data blocks or areas 812. These elements may be "packaged" 
within a "container" 302. This generalized, logical object 
structure 800 is used in the preferred embodiment for 
different types of VDE objects 300 categorized by the type 
and location of their content. 

The "container" concept is a convenient metaphor used to 
give a name to the collection of elements required to make 
use of content or to perform an administrative -type activity. 
Container 302 typically includes identifying information, 
control structures and content (e.g., a property or adminis- 
trative data). The term "container" is often (e.g., Bento/ 
Open Doc and OLE) used to describe a collection of infor- 
mation stored on a computer system's secondary storage 
system(s) or accessible to a computer system over a com- 
munications network on a "server's" secondary storage 
system. The "container" 302 provided by the preferred 
embodiment is not so limited or restricted. In VDE 100, 
there is no requirement that this information is stored 
together, received at the same time, updated at the same 
time, used for only a single object, or be owned by the same 
entity. Rather, in VDE 100 the container concept is extended 
and generalized to include real-time content and/or online 
interactive content passed to an electronic appliance over a 
cable, by broadcast, or communicated by other electronic 
communication means. 

Thus, the "complete" VDE container 302 or logical object 
structure 800 may not exist at the user's location (or any 
other location, for that matter) at any one time. The "logical 
object" may exist over a particular period of time (or periods 
of time), rather than all at once. This concept includes the 
notion of a "virtual container" where important container 
elements may exist either as a plurality of locations and/or 
over a sequence of time periods (which may or may not 
overlap). Of course, VDE 100 containers can also be stored 
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with all required control structures and content together. will be enhanced by using at least one key block 810 for each 

This represents a continuum: from all content and control data block 812 in the object, although this is not required, 

structures present in a single container, to no locally acces- Key blocks 810 may also span portions of a plurality of data 

sible content or container specific control structures. blocks 812 in a consistent or pseudo-random manner. The 

Although at least some of the data representing the object 5 spanning may provide additional security by applying one or 

is typically encrypted and thus its structure is not more keys to fragmented or seemingly random pieces of 

discernible, within a PPE 650 the object may be viewed content contained in an object 300, database, or other 

logically as a "container" 302 because its structure and information entity. 

components are automatically and transparently decrypted. Many objects 300 that are distributed by physical media 

A container model merges well with the event-driven 10 and/or by "out of channel" means (e.g., redistributed after 

processes and ROS 602 provided by the preferred embodi- receipt by a customer to another customer) might not include 

ment. Under this model, content is easily subdivided into key blocks 810 in the same object 300 that is used to 

small, easily manageable pieces, but is stored so that it transport the content protected by the key blocks. This is 

maintains the structural richness inherent in unencrypted because VDE objects may contain data that can be elec- 

content. An object oriented container model (such as Bento/ is tronically copied outside the confines of a VDE node. If the 

OpenDoc or OLE) also provides many of the necessary content is encrypted, the copies will also be encrypted and 

"hooks" for inserting the necessary operating system inte- the copier cannot gain access to the content unless she has 

gration components, and for defining the various content the appropriate decryption key(s). For objects in which 

specific methods. maintaining security is particularly important, the permis- 

In more detail, the logical object structure 800 provided 20 sion records 808 and key blocks 810 will frequently be 

by the preferred embodiment includes a public (or distributed electronically, using secure communications 

unencrypted) header 802 that identifies the object and may techniques (discussed below) that are controlled by the VDE 

also identify one or more owners of rights in the object nodes of the sender and receiver. As a result, permission 

and/or one or more distributors of the object. Private (or records 808 and key blocks 810 will frequently, in the 

encrypted) header 804 may include a part or all of the 25 preferred embodiment, be stored only on electronic appli- 

information in the public header and further, in the preferred ances 600 of registered users (and may themselves be 

embodiment, will include additional data for validating and delivered to the user as part of a registration/initialization 

identifying the object 300 when a user attempts to register as process). In this instance, permission records 808 and key 

a user of the object with a service clearinghouse, VDE blocks 810 for each property can be encrypted with a private 

administrator, or an SPU 500. Alternatively, information 30 DES key that is stored only in the secure memory of an SPU 

identifying one or more rights owners and/or distributors of 500, making the key blocks unusable on any other user's 

the object may be located in encrypted form within VDE node. Alternately, the key blocks 810 can be encrypted 

encrypted header 804, along with any of said additional with the end user's public key, making those key blocks 

validating and identifying data. usable only to the SPU 500 that stores the corresponding 

Each logical object structure 800 may also include a 35 private key (or other, acceptably secure, encryption/security 

"private body" 806 containing or referencing a set of meth- techniques can be employed). 

ods 1000 (i.e., programs or procedures) that control use and In the preferred embodiment, the one or more keys used 

distribution of the object 300. The ability to optionally to encrypt each permission record 808 or other management 

incorporate different methods 1000 with each object is information record will be changed every time the record is 

important to making VDE 100 highly configurable. Methods 40 updated (or after a certain one or more events). In this event, 

1000 perform the basic function of defining what users the updated record is re -encrypted with new one or more 

(including, where appropriate, distributors, client keys. Alternately, one or more of the keys used to encrypt 

administrators, etc.), can and cannot do with an object 300. and decrypt management information may be "time aged" 

Thus, one object 300 may come with relatively simple keys that automatically become invalid after a period of 

methods, such as allowing unlimited viewing within a fixed 45 time. Combinations of time aged and other event triggered 

period of lime for a fixed fee (such as the newsstand price keys may also be desirable; for example keys may change 

of a newspaper for viewing the newspaper for a period of after a certain number of accesses, and/or after a certain 

one week after the paper's publication), while other objects duration of time or absolute point in time. The techniques 

may be controlled by much more complicated (e.g., billing may also be used together for any given key or combination 

and usage limitation) methods. 50 of keys. The preferred embodiment procedure for construct - 

Logical object structure 800 shown in FIG. 17 may also ing time aged keys is a one-way convolution algorithm with 

include one or more PERCs 808. PERCs 808 govern the use input parameters including user and site information as well 

of an object 300, specifying methods or combinations of as a specified portion of the real time value provided by the 

methods that must be used to access or otherwise use the SPU RTC 528. Other techniques for time aging may also be 

object or its contents. The permission records 808 for an 55 used, including for example techniques that use only user or 

object may include key block(s) 810, which may store site information, absolute points in time, and/or duration of 

decryption keys for accessing the content of the encrypted time related to a subset of activities related to using or 

content stored within the object 300. decrypting VDE secured content or the use of the VDE 

The content portion of the object is typically divided into system, 

portions called data blocks 812. Data blocks 812 may 60 VDE 100 supports many different types of "objects" 300 

contain any sort of electronic information, such as, having the logical object structure 800 shown in FIG. 17. 

"content," including computer programs, images, sound, Objects may be classified in one sense based on whether the 

VDE administrative information, etc. The size and number protection information is bound together with the protected 

of data blocks 812 may be selected by the creator of the information. For example, a container that is bound by its 

property. Data blocks 812 need not all be the same size (size 65 controls) to a specific VDE node is called a "stationary 

may be influenced by content usage, database format, oper- object" (see FIG. 18). A container that is not bound by its 

ating system, security and/or other considerations). Security control information to a specific VDE node but rather carries 
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sufficient control and permissions to permit its use, in whole 
or in part, at any of several sites is called a "Traveling 
Object" (see FIG. 19). 

Objects may be classified in another sense based on the 
nature of the information they contain. A container with 5 
information content is called a "Content Object** (see FIG. 
20). A container that contains transaction information, audit 
trails, VDE structures, and/or other VDE control/ 
administrative information is called an "Administrative 
Object" (see FIG. 21). Some containers that contain execut- 10 
able code operating under VDE control (as opposed to being 
VDE control information) are called "Smart Objects." Smart 
Objects support user agents and provide control for their 
execution at remote sites. There are other categories of 
objects based upon the location, type and access mechanism is 
associated with their content, that can include combinations 
of the types mentioned above. Some of these objects sup- 
ported by VDE 100 are described below. Some or all of the 
data blocks 812 shown in FIG. 17 may include "embedded" 
content, administrative, stationary, traveling and/or other 20 
objects. 

1. Stationary Objects 

FIG. 18 shows an example of a "Stationary Object" 
structure 850 provided by the preferred embodiment. "Sta- 
tionary Object" structure 850 is intended to be used only at 25 
specific VDE electronic appliance/installations that have 
received explicit permissions to use one or more portions of 
the stationary object. Therefore, stationary object structure 
850 does not contain a permissions record (PERC) 808; 
rather, this permissions record is supplied and/or delivered 30 
separately (e.g., at a different time, over a different path, 
and/or by a different party) to the appliance/installation 600. 
A common PERC 808 may be used with many different 
stationary objects. 

As shown in FIG. 18, public header 802 is preferably 35 
"plaintext" (i.e., unencrypted), Private header 804 is pref- 
erably encrypted using at least one of many "private header 
keys/* Private header 804 preferably also includes a copy of 
identification elements from public header 802, so that if the 
identification information in the plaintext public header is 40 
tampered with, the system can determine precisely what the 
tamperer attempted to alter. Methods 1000 may be contained 
in a section called the "private body" 806 in the form of 
object local methods, load modules, and/or user data ele- 
ments. This private body (method) section 806 is preferably 45 
encrypted using one or more private body keys contained in 
the separate permissions record 808. The data blocks 812 
contain content (information or administrative) that may be 
encrypted using one or more content keys also provided in 
permissions record 808. 50 

2. Traveling Objects 

FIG. 19 shows an example of a "traveling object" struc- 
ture 860 provided by the preferred embodiment. Traveling 
objects are objects that carry with them sufficient informa- 
tion to enable at least some use of at least a portion of their 55 
content when they arrive at a VDE node. 

Traveling object structure 860 may be the same as sta- 
tionary object structure 850 shown in FIG. 18 except that the 
traveling object structure includes a permissions record 
(PERC) 808 within private header 804. The inclusion of 60 
PERC 808 within traveling object structure 860 permits the 
traveling object to be used at any VDE electronic appliance/ 
participant 600 (in accordance with the methods 1000 and 
the contained PERC 808). 

"Traveling" objects are a class of VDE objects 300 that 65 
can specifically support "out of channel" distribution. 
Therefore, they include key block(s) 810 and are transport- 
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able from one electronic appliance 600 to another. Traveling 
objects may come with a quite limited usage related budget 
so that a user may use, in whole or part, content (such as a 
computer program, game, or database) and evaluate whether 
to acquire a license or further license or purchase object 
content. Alternatively, traveling object PERCs 808 may 
contain or reference budget records with, for example: 

(a) budgets) reflecting previously purchased rights or 
credit for future licensing or purchasing and enabling at 
least one or more types of object content usage, and/or 

(b) budgets) that employ (and may debit) available 
credits) stored on and managed by the local VDE node 
in order to enable object content use, and/or 

(c) budgets) reflecting one or more maximum usage 
criteria before a report to a local VDE node (and, 
optionally, also a report to a clearinghouse) is required 
and which may be followed by a reset allowing further 
usage, and/or modification of one or more of the 
original one or more budgets). 

As with standard VDE objects 300, a user may be required 
to contact a clearinghouse service to acquire additional 
budgets if the user wishes to continue to use the traveling 
object after the exhaustion of an available budget(s) or if the 
traveling object (or a copy thereof) is moved to a different 
electronic appliance and the new appliance does not have a 
available credit budget(s) that corresponds to the require- 
ments stipulated by permissions record 808. 

For example, a traveling object PERC 808 may include a 
reference to a required budget VDE 1200 or budget options 
that may be found and/or are expected to be available. For 
example, the budget VDE may reference a consumer's 
VISA, MC, AMEX, or other "generic" budget that may be 
object independent and may be applied towards the use of a 
certain or classes of traveling object content (for example 
any movie object from a class of traveling objects that might 
be Blockbuster Video rentals). The budget VDE itself may 
stipulate one or more classes of objects it may be used with, 
while an object may specifically reference a certain one or 
more generic budgets. Under such circumstances, VDE 
providers will typically make information available in such 
a manner as to allow correct referencing and to enable 
billing handling and resulting payments. 

Traveling objects can be used at a receiving VDE node 
electronic appliance 600 so long as either the appliance 
carries the correct budget or budget type (e.g. sufficient 
credit available from a clearinghouse such as a VISA 
budget) either in general or for specific one or more users or 
user classes, or so long as the traveling object itself carries 
with it sufficient budget allowance or an appropriate autho- 
rization (e.g., a stipulation that the traveling object may be 
used on certain one or more installations or installation 
classes or users or user classes where classes correspond to 
a specific subset of installations or users who are represented 
by a predefined class identifiers stored in a secure database 
610). After receiving a traveling object, if the user (and/or 
installation) doesn't have the appropriate budget(s) and/or 
authorizations, then the user could be informed by the 
electronic appliance 600 (using information stored in the 
traveling object) as to which one or more parties the user 
could contact. The party or parties might constitute a list of 
alternative clearinghouse providers for the traveling object 
from which the user selects his desired contact). 

As mentioned above, traveling objects enable objects 300 
to be distributed "Out-Of-Channel;" that is, the object may 
be distributed by an unauthorized or not explicitly autho- 
rized individual to another individual. "Out of channel" 
includes paths of distribution that allow, for example, a user 
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to directly redistribute an object to another individual. For 
example, an object provider might allow users to redistribute 
copies of an object to their friends and associates (for 
example by physical delivery of storage media or by deliv- 
ery over a computer network) such that if a friend or 5 
associate satisfies any certain criteria required for use of said 
object, he may do so. 

For example, if a software program was distributed as a 
traveling object, a user of the program who wished to supply 
it or a usable copy of it to a friend would normally be free 10 
to do so. Traveling Objects have great potential commercial 
significance, since useful content could be primarily distrib- 
uted by users and through bulletin boards, which would 
require little or no distribution overhead apart from regis- 
tration with the "original" content provider and/or clearing- 15 
house. 

The "out of channel" distribution may also allow the 
provider to receive payment for usage and/or elsewise 
maintain at least a degree of control over the redistributed 
object. Such certain criteria might involve, for example, the 20 
registered presence at a user's VDE node of an authorized 
third party financial relationship, such as a credit card, along 
with sufficient available credit for said usage. 

Thus, if the user had a VDE node, the user might be able 
to use the traveling object if he had an appropriate, available 25 
budget available on his VDE node (and if necessary, allo- 
cated to him), and/or if he or his VDE node belonged to a 
specially authorized group of users or installations and/or if 
the traveling object carried its own budget(s). 

Since the content of the traveling object is encrypted, it 30 
can be used only under authorized circumstances unless the 
traveling object private header key used with the object is 
broken — a potentially easier task with a traveling object as 
compared to, for example, permissions and/or budget infor- 
mation since many objects may share the same key, giving 35 
a cryptoanalyst both more information in cyphertext to 
analyze and a greater incentive to perform cryptoanalysis. 

In the case of a "traveling object/' content owners may 
distribute information with some or all of the key blocks 810 
included in the object 300 in which the content is encapsu- 40 
lated. Putting keys in distributed objects 300 increases the 
exposure to attempts to defeat security mechanisms by 
breaking or crypto analyzing the encryption algorithm with 
which the private header is protected (e.g., by determining 
the key for the header's encryption). This breaking of 45 
security would normally require considerable skill and time, 
but if broken, the algorithm and key could be published so 
as to allow large numbers of individuals who possess objects 
that are protected with the same key(s) and algorithm(s) to 
illegally use protected information. As a result, placing keys 50 
in distributed objects 300 may be limited to content that is 
either "time sensitive" (has reduced value after the passage 
of a certain period of time), or which is somewhat limited in 
value, or where the commercial value of placing keys in 
objects (for example convenience to end-users, lower cost of 55 
eliminating the telecommunication or other means for deliv- 
ering keys and/or permissions information and/or the ability 
to supporting objects going "out-of-channel") exceeds the 
cost of vulnerability to sophisticated hackers. As mentioned 
elsewhere, the security of keys may be improved by employ- 60 
ing convolution techniques to avoid storing "true" keys in a 
traveling object, although in most cases using a shared secret 
provided to most or all VDE nodes by a VDE administrator 
as an input rather than site ID and/or time in order to allow 
objects to remain independent of these values. 65 

As shown in FIG. 19 and discussed above, a traveling 
object contains a permissions record 808 that preferably 
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provides at least some budget (one, the other, or both, in a 
general case). Permission records 808 can, as discussed 
above, contain a key block(s) 810 storing important key 
information. PERC 808 may also contain or refer to budgets 
containing potentially valuable quantities/values. Such bud- 
gets may be stored within a traveling object itself, or they 
may be delivered separately and protected by highly secure 
communications keys and administrative object keys and 
management database techniques. 

The methods 1000 contained by a traveling object will 
typically include an installation procedure for "self regis- 
tering" the object using the permission records 808 in the 
object (e.g., a REGISTER method). This may be especially 
useful for objects that have time limited value, objects (or 
properties) for which the end user is either not charged or is 
charged only a nominal fee (e.g., objects for which adver- 
tisers and/or information publishers are charged based on the 
number of end users who actually access published 
information), and objects that require widely available bud- 
gets and may particularly benefit from out-of-channel dis- 
tribution (e.g., credit card derived budgets for objects con- 
taining properties such as movies, software programs, 
games, etc.). Such traveling objects may be supplied with or 
without contained budget UDEs. 

One use of traveling objects is the publishing of software, 
where the contained permission record(s) may allow poten- 
tial customers to use the software in a demonstration mode, 
and possibly to use the full program features for a limited 
time before having to pay a license fee, or before having to 
pay more than an initial trial fee. For example, using a time 
based billing method and budget records with a smalt 
pre-installed time budget to allow full use of the program for 
a short period of time. Various control methods may be used 
to avoid misuse of object contents. For example, by setting 
the minimum registration interval for the traveling object to 
an appropriately large period of time (e.g., a month, or six 
months or a year), users are prevented from re-using the 
budget records in the same traveling object. 

Another method for controlling the use of traveling 
objects is to include time -aged keys in the permission 
records that are incorporated in the traveling object. This is 
useful generally for traveling objects to ensure that they will 
not be used beyond a certain date without re-registration, 
and is particularly useful for traveling objects that are 
electronically distributed by broadcast, network, or telecom- 
munications (including both one and two way cable), since 
the date and time of delivery of such traveling objects aging 
keys can be set to accurately correspond to the time the user 
came into possession of the object. 

Traveling objects can also be used to facilitate "moving" 
an object from one electronic appliance 600 to another. A 
user could move a traveling object, with its incorporated one 
or more permission records 808 from a desktop computer, 
for example, to bis notebook computer. A traveling object 
might register its user within itself and thereafter only be 
useable by that one user. A traveling object might maintain 
separate budget information, one for the basic distribution 
budget record, and another for the "active" distribution 
budget record of the registered user. In this way, the object 
could be copied and passed to another potential user, and 
then could be a portable object for that user. 

Traveling objects can come in a container which contains 
other objects. For example, a traveling object container can 
include one or more content objects and one or more 
administrative objects for registering the content objects) in 
an end user's object registry and/or for providing mecha- 
nisms for enforcing permissions and/or other security func- 
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tions. Contained administrative object(s) may be used to 
install necessary permission records and/or budget informa- 
tion in the end user's electronic appliance. 
Content Objects 

FIG. 20 shows an example of a VDE content object 5 
structure 880. Generally, content objects 880 include or 
provide information content. This "content" may be any sort 
of electronic information. For example, content may 
include: computer software, movies, books, music, informa- 
tion databases, multimedia information, virtual reality 10 
information, machine instructions, computer data files, com- 
munications messages and/or signals, and other information, 
at least a portion of which is used and/or manipulated by one 
or more electronic appliances. VDE 100 can also be con- 
figured for authenticating, controlling, and/or auditing elec- 15 
tronic commercial transactions and communications such as 
inter-bank transactions, electronic purchasing 
communications, and the transmission of, auditing of, and 
secure commercial archiving of, electronically signed con- 
tracts and other legal documents; the information used for 20 
these transactions may also be termed "content." As men- 
tioned above, the content need not be physically stored 
within the object container but may instead be provided 
separately at a different time (e.g., a real time feed over a 
cable). 25 

Content object structure 880 in the particular example 
shown in FIG. 20 is a type of stationary object because it 
does not include a PERC 808. In this example, content 
object structure 880 includes, as at least part of its content 
812, at least one embedded content object 882 as shown in 30 
FIG. 5A. Content object structure 880 may also include an 
administrative object 870. Thus, objects provided by the 
preferred embodiment may include one or more "embed- 
ded" objects. 

Administrative Objects 35 
FIG. 21 shows an example of an administrative object 
structure 870 provided by the preferred embodiment. An 
"administrative object" generally contains permissions, 
administrative control information, computer software and/ 
or methods associated with the operation of VDE 100. 40 
Administrative objects may also or alternatively contain 
records of use, and/or other information used in, or related 
to, the operation of VDE 100. An administrative object may 
be distinguished from a content object by the absence of 
VDE protected "content" for release to an end user for 45 
example. Since objects may contain other objects, it is 
possible for a single object to contain one or more content 
containing objects and one or more administrative objects. 
Administrative objects may be used to transmit information 
between electronic appliances for update, usage reporting, 50 
billing and/or control purposes. They contain information 
that helps to administer VDE 100 and keep it operating 
properly. Administrative objects generally are sent between 
two VDE nodes, for example, a VDE clearinghouse service, 
distributor, or client administrator and an end user's elec- 55 
ji tronic appliance 600. 

Administrative object structure 870 in this example 
includes a public header 802, private header 804 (including 
a "PERC 808) and a "private body" 806 containing meth- 
ods 1000. Administrative object structure 870 in this par- 60 
ticular example shown in FIG. 20 is a type of traveling 
object because it contains a PERC 808, but the administra- 
tive object could exclude the PERC 808 and be a stationary 
object. Rather than storing information content, administra- 
tive object structure 870 stores "administrative information 65 
content" 872. Administrative information content 872 may, 
for example, comprise a number of records 872a, 8726, . . 



. 872n each corresponding to a different "event." Each 
record 872a, 872i>, , . , 812n may include an "event" field 
874, and may optionally include a parameter field 876 and/or 
a data field 878. These administrative content records 872 
may be used by VDE 100 to define events that may be 
processed during the course of transactions, e.g., an event 
designed to add a record to a secure database might include 
parameters 896 indicating how and where the record should 
be stored and data field 878 containing the record to be 
added. In another example, a collection of events may 
describe a financial transaction between the creators) of an 
administrative object and the recipient(s), such as a 
purchase, a purchase order, or an invoice. Each event record 
872 may be a set of instructions to be executed by the end 
user's electronic appliance 600 to make an addition or 
modification to the end user's secure database 610, for 
example. Events can perform many basic management 
functions, for example: add an object to the object registry, 
including providing the associated user/group record(s), 
rights records, permission record and/or method records; 
delete audit records (by "rolling up" the audit trail informa- 
tion into, for example, a more condensed, e.g. summary 
form, or by actual deletion); add or update permissions 
records 808 for previously registered objects; add or update 
budget records; add or update user rights records; and add or 
update load modules. 

In the preferred embodiment, an administrative object 
may be sent, for example, by a distributor, client 
administrator, or, perhaps, a clearinghouse or other financial 
service provider, to an end user, or, alternatively, for 
example, by an object creator to a distributor or service 
clearinghouse. Administrative objects, for example, may 
increase or otherwise adjust budgets and/or permissions of 
the receiving VDE node to which the administrative object 
is being sent. Similarly, administrative objects containing 
audit information in the data area 878 of an event record 872 
can be sent from end users to distributors, and/or clearing- 
houses and/or client administrators, who might themselves 
further transmit to object creators or to other participants in 
the object's chain of handling. 

Methods 

Methods 1000 in the preferred embodiment support many 
of the operations that a user encounters in using objects and 
communicating with a distributor. They may also specify 
what method fields are displayable to a user (e.g., use events, 
user request events, user response events, and user display 
events). Additionally, if distribution capabilities are sup- 
ported in the method, then the method may support distri- 
bution activities, distributor communications with a user 
about a method, method modification, what method fields 
are displayable to a distributor, and any distribution database 
checks and record keeping (e.g., distribution events, dis- 
tributor request events, and distributor response events). 

Given the generality of the existing method structure, and 
the diverse array of possibilities for assembling methods, a 
generalized structure may be used for establishing relation- 
ships between methods. Since methods 1000 may be inde- 
pendent of an object that requires them during any given 
session, it is not possible to define the relationships within 
the methods themselves. "Control methods" are used in the 
preferred embodiment to define relationships between meth- 
ods. Control methods may be object specific, and may 
accommodate an individual object's requirements during 
each session. 

A control method of an object establishes relationships 
between other methods. These relationships are parameter- 
ized with explicit method identifiers when a record set 
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reflecting desired method options for each required method 
is constructed during a registration process. 

An "aggregate method" in the preferred embodiment 
represents a collection of methods that may be treated as a 
single unit. A collection of methods that are related to a 
specific property, for example, may be stored in an aggregate 
method. This type of aggregation is useful from an imple- 
mentation point of view because it may reduce bookkeeping 
overhead and may improve overall database efficiency. Id 
other cases, methods may be aggregated because they are 
logically coupled. For example, two budgets may be linked 
together because one of the budgets represents an overall 
limitation, and a second budget represents the current limi- 
tation available for use. This would arise if, for example, a 
large budget is released in small amounts over time. 

For example, an aggregate method that includes meter, 
billing and budget processes can be used instead of three 
separate methods. Such an aggregate method may reference 
a single "load module" 1100 that performs all of the func- 
tions of the three separate load modules and use only one 
user data element that contains meter, billing and budget 
data. Using an aggregate method instead of three separate 
methods may minimize overall memory requirements, data- 
base searches, decryptions, and the number of user data 
element writes back to a secure database 610. The disad- 
vantage of using an aggregate method instead of three 
separate methods can be a loss of some flexibility on the part 
of a provider and user in that various functions may no 
longer be independently replaceable. 

FIG. 16 shows methods 1000 as being part of secure 
database 610. 

A "method" 1000 provided by the preferred embodiment 
is a collection of basic instructions and information related 
to the basic instructions, that provides context, data, require- 
ments and/or relationships for use in performing, and/or 
preparing to perform, the basic instructions in relation to the 
operation of one or more electronic appliances 600. As 
shown in FIG. 16, methods 1000 in the preferred embodi- 
ment are represented in secure database 610 by: 

method "cores" 1000'; 

Method Data Elements (MDEs) 1202; 

User Data Elements (UDEs) 1200; and 

Data Description Elements (DTDs). 

Method "core" 1000 1 in the preferred embodiment may 
contain or reference one or more data elements such as 
MDEs 1202 and UDEs 1200. In the preferred embodiment, 
MDEs 1202 and UDEs 1200 may have the same general 
characteristics, the main difference between these two types 
of data elements being that a UDE is preferably tied to a 
particular method as well as a particular user or group of 
users, whereas an MDE may be tied to a particular method 
but may be user independent. These MDE and UDE data 
structures 1200, 1202 are used in the preferred embodiment 
to provide input data to methods 1000, to receive data 
outputted by methods, or both. MDEs 1202 and UDEs 1200 
may be delivered independently of method cores 1000' that 
reference them, or the data structures may be delivered as 
part of the method cores. For example, the method core 
1000' in the preferred embodiment may contain one or more 
MDEs 1202 and/or UDEs 1200 (or portions thereof). 
Method core 1000' may, alternately or in addition, reference 
one or more MDE and/or UDE data structures that are 
delivered independently of method core(s) that reference 
them. 

Method cores 1000' in the preferred embodiment also 
reference one or more "load modules" U00. Load modules 
1100 in the preferred embodiment comprise executable 
code, and may also include or reference one or more data 
structures called "data descriptor" ("DTD") information. 
This "data descriptor" information may, for example, pro- 
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vide data input information to the DTD interpreter 590. 
DTDs may enable load modules 1100 to access (e.g., read 
from and/or write to) the MDE and/or UDE data elements 
1202, 1200. 

5 Method cores 1000' may also reference one or more DTD 
and/or MDE data structures that contain a textual description 
of their operations suitable for inclusion as part of an 
electronic contract. The references to the DTD and MDE 
data structures may occur in the private header of the method 

10 core 1000', or may be specified as part of the event table 
described below. 

FIG. 22 shows an example of a format for a method core 
1000' provided by the preferred embodiment. A method core 
1000' in the preferred embodiment contains a method event 

15 table 1006 and a method local data area 1008. Method event 
table 1006 lists "events." These "events" each reference 
"load modules" 1100 and/or PERCs 808 that control pro- 
cessing of an event. Associated with each event in the list is 
any static data necessary to parameterize the load module 

20 1000 or permissions record 808, and reference(s) into 
method user data area 1008 that are needed to support that 
event. The data that parameterizes the load module 1100 can 
be thought of, in part, as a specific function call to the load 
module, and the data elements corresponding to it may be 

25 thought of as the input and/or output data for that specific 
function call. 

Method cores 1000' can be specific to a single user, or 
they may be shared across a number of users (e.g., depend- 
ing upon the uniqueness of the method core and/or the 

30 specific user data element). Specifically, each user/group 
may have its own UDE 1200 and use a shared method core 
1000', This structure allows for lower database overhead 
than when associating an entire method core 1000' with a 
user/group. To enable a user to use a method, the user may 

35 be sent a method core 1000' specifying a UDE 1200. If that 
method core 1000' already exists in the site's secure data- 
base 610, only the UDE 1200 may need to be added. 
Alternately, the method may create any required UDE 1200 
at registration time. 

40 The FIG. 22 example of a format for a method core 1000' 
provided by the preferred embodiment includes a public 
(unencrypted) header 802, a private (encrypted) header 804, 
method event table 1006, and a method local data area 1008. 
An example of a possible field layout for method core 

45 1000' public header 802 is shown in the following table: 
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Field Type 


Description 


Method ID 


Creator ID 


Site ID of creator of this 






method. 




Distributor ID 


Distributor of this method 






(e.g., last change). 




Type ID 


Constant, indicates method 






"type." 




Method ID 


Unique sequence number 






for this method. 




Version ID 


Version number of this 






method 


Othex 


Class ID 


ID to support different 


classification 




method "classes." 


information 


T>pe ID 


ID to support method type 






compatible searching. 


Descriptive 


Description(s) 


Textual description^) of the 


information 




method. 




Event 


Summary of event classes 




Summary 


(e.g., USE) that this method 






supports. 
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An example of a possible field layout for private header 
804 is shown below: 
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Field type 




Description 


Copy of Public Header 802 Method ID 


Method ID from 


and "Other Classification 


Public Header 


Information" 






Descriptive 


# of Events 


# of events supported 


Information 




in this method. 


Access and 


Access tag 


Tags used to 


Reference lags 




determine if this 
method is the 
correct method 




Validation tag 


under management 
by the SPU; ensure 
that the method 
core 1000' Ls used 




Correlation tag 


only under 
appropriate 
circumstances. 


Data Structure Reference 


Optional Reference to 






DTD(s) and/or 






MDE(s) 


Check \felue 




Check value for 
Private Header and 
method event table. 


Check \fclue for Public Header 


Check Value for 






Public Header 
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Referring once again to FIG. 22, method event table 1006 
may in the preferred embodiment include from 1 to N 
method event records 1012, Each of these method event 
records 1012 corresponds to a different event the method 
1000 represented by method core 1000' may respond to. 
Methods 1000 in the preferred embodiment may have com- 
pletely different behavior depending upon the event they 
respond to. For example, an AUDIT method may store 
information in an audit trail UDE 1200 in response to an 
event corresponding to a user's use of an object or other 
resource. This same AUDIT method may report the stored 
audit trail to a VDE administrator or other participant in 
response to an administrative event such as, for example, a 
timer expiring within a VDE node or a request from another 
VDE participant to report the audit trail. In the preferred 
embodiment, each of these different events may be repre- 
sented by an "event code." This "event code" may be passed 
as a parameter to a method when the method is called, and 
used to "look up" the appropriate method event record 1012 
within method event table 1006. The selected method event 
record 1012, in turn, specifies the appropriate information 
(e.g., load module(s) 1100, data element UDE(s) and MDE 
(s) 1200, 1202, and/or PERC(s) 808) used to construct a 
component assembly 690 for execution in response to the 
event that has occurred. 

Thus, in the preferred embodiment, each method event 
record 1012 may include an event field 1014, a LM/PERC 
reference field 1016, and any number of data reference fields 
1018, Event fields 1014 in the preferred embodiment may 
contain a "event code" or other information identifying the 
corresponding event. The LM/PERC reference field 1016 
may provide a reference into the secure database 610 (or 
other "pointer** information) identifying a load module U00 
and/or a PERC 808 providing (or referencing) executable 
code to be loaded and executed to perform the method in 
response to the event. Data reference fields 1018 may 
include information referencing a UDE 1200 or a MDE 
1202. These data structures may be contained in the method 
local data area 1008 of the method core 1000', or they may 
be stored within the secure database 610 as independent 
deliverables. 

The following table is an example of a possible more 
detailed field layout for a method event record 1012: 
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Field Type 




Description 


Event Field 1014 




Identifies corresponding 






event. 


Access tag 




Secret tag to grant access to 






this row of the method 






event record. 


LM/PERC 


DB ID or 


Database reference (or local 


Reference 


offset/size 


pointer). 


Field 1016 


Correlation tag 


Correlation tag to assert 






when referencing this 






element. 


# of Data Element Reference 


Count of data reference 


Fields 




fields in the method event 






record. 


Data 


UDE ID or 


Database 610 reference (or 


Reference 


offset/size 


local pointer). 


Field 1 


Correlation tag 


Correlation tag to assert 






when referencing this 






element. 


Data 


UDE ID or 


Database 610 reference (or 


Reference 


offset/size 


local pointer). 


Field n 


Correlation tag 


Correlation tag to assert 






when referencing this 






element. 



Load Modules 

FIG. 23 is an example of a load module 1100 provided by 
the preferred embodiment. In general, load modules 1100 
represent a collection of basic functions that are used for 
control operations. 

Load module 1100 contains code and static data (that is 
functionally the equivalent of code), and is used to perform 
the basic operations of VDE 100. Load modules 1100 will 
generally be shared by all the control structures for all 
objects in the system, though proprietary load modules are 
also permitted. Load modules 1100 may be passed between 
VDE participants in administrative object structures 870, 
and are usually stored in secure database 610. They are 
always encrypted and authenticated in both of these cases. 
When a method core 1000' references a load module 1100, 
a load module is loaded into the SPE 503, decrypted, and 
then either passed to the electronic appliance microprocessor 
for executing in an HPE 655 (if that is where it executes), or 
kept in the SPE (if that is where it executes). If no SPE 503 
is present, the load module may be decrypted by the HPE 
655 prior to its execution. 

Load module creation by parties is preferably controlled 
by a certification process or a ring based SPU architecture. 
Tmis, the process of creating new load modules U00 is itself 
50 a controlled process, as is the process of replacing, updating 
or deleting load modules already stored in a secured data- 
base 610. 

A load module 1100 is able to perform its function only 
when executed in the protected environment of an SPE 503 
or an HPE 655 because only then can it gain access to the 
protected elements (e.g., UDEs 1200, other load modules 
1100) on which it operates. Initiation of load module execu- 
tion in this environment is strictly controlled by a combi- 
nation of access tags, validation tags, encryption keys, 
60 digital signatures and/or correlation tags. Thus, a load mod- 
ule 1100 may only be referenced if the caller knows its ID 
and asserts the shared secret correlation tag specific to that 
load module. The decrypting SPU may match the identifi- 
cation token and local access tag of a load module after 
65 decryption. These techniques make the physical replacement 
of any load module 1100 detectable at the next physical 
access of the load module. Furthermore, load modules 1100 
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may be made "read only" in the preferred embodiment. The 
read-only nature of load modules 1100 prevents the write- 
back of load modules that have been tampered with in 
non-secure space. 

Load modules are not necessarily directly governed by 
PERCs 808 that control them, nor must they contain any 
time/date information or expiration dates. The only control 
consideration in the preferred embodiment is that one or 
more methods 1000 reference them using a correlation tag 
(the value of a protected object created by the load module's 
owner, distributed to authorized parties for inclusion in their 
methods, and to which access and use is controlled by one 
or more PERCs 808). If a method core 1000* references a 
load module 1100 and asserts the proper correlation tag (and 
the load module satisfies the internal tamper checks for the 
SPE 503), then that load module can be loaded and executed, 
or it can be acquired from, shipped to, updated, or deleted 
by, other systems. 

As shown in FIG. 23, load modules 1100 in the preferred 
embodiment may be constructed of a public (unencrypted) 
header 802, a private (encrypted) header 804, a private body 
1106 containing the encrypted executable code, and one or 
more data description elements ("DTDs") 1108. The DTDs 
1108 may be stored within a load module 1100, or they may 
be references to static data elements stored in secure data- 
base 610. 

The following is an example of a possible field layout for 
load module public header 802: 



Field Type 



Description 



LM ID 




VDE [D of Load Module. 




Creator ID 


Site ID of creator of this load 
module. 




Type ID 


Constant indicates load 




module type. 




LM ID 


Unique sequence number for 
this load module, which 
uniquely identifies the load 
module in a sequence of load 
modules created by an 
authorized VDE participant. 




Version ID 


Version number of this load 
module. 


Other 


Cass ID 


ID to support different load 


classification 




module classes. 


information 


Type ID 


ID to support method type 
compatible searching. 


Descriptive 


Description 


Textual description of the 


Information 




load module. 




Execution 


Value that describes what 




space code 


execution space (e.g., SPE or 
HPE) this load module. 



Many load modules 1100 contain code that executes in an 
SPE 503. Some load modules 1100 contain code that 
executes in an HPE 655. This allows methods 1000 to 
execute in whichever environment is appropriate. For 
example, an INFORMATION method 1000 can be built to 
execute only in SPE 503 secure space for government 
classes of security, or in an HPE 655 for commercial 
applications. As described above, the load module public 
header 802 may contain an "execution space code" field that 
indicates where the load module 1100 needs to execute. This 
functionality also allows for different SPE instruction sets as 
well as different user platforms, and allows methods to be 
constructed without dependencies on the underlying load 
module instruction set. 

Load modules 1100 operate on three major data areas: the 
stack, load module parameters, and data structures. The 
stack and execution memory size required to execute the 
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load module 1100 are preferably described in private header 
804, as are the data descriptions from the stack image on 
load module call, return, and any return data areas. The stack 
and dynamic areas are described using the same DTD 
mechanism. The following is an example of a possible 
layout for a load module private header 1104: 



Field Type 



Description 



10 



Copy of some or all of information Object ID from Public Header, 
from public header 802 



Other 
classification 
information 
Descriptive 
Information 



Access and 
reference tags 



25 



Data record 

descriptor 

information 



Check Value 



LM Size 
LM Exec Size 

LM Exec Stack 

Execution space 
code 

Access tag 
^Validation tag 

Correlation tag 



Digital Signature 



DTD count 



DTD 1 reference 



35 



Check Value 



Check Value for Public Header. 



Size of executable code block. 
Executable code size for the load 
module. 

Stack size required for the load 
module. 

Code that describes the execution 
space for this load module. 
Tags used to determine if the load 
module is the correct LM requested 
by the SPE, 

Tag used to determine if the caller 
of the LM has the right to execute 
this LM. 

Used to determine if the LM 
executable content is intact and 
was created by a trusted source 
(one with a correct certificate for 
creating LMs). 

Number of DTDs that follow the 
code block. 

If locally defined, the physical size 
and offset in bytes of the first DTD 
defined for this LM. 
If publicly referenced DTD, this is 
the DTD ID and the correlation tag 
to permit access to the record. 



DTD N reference If locally defined, the physical size 
and oflset in bytes of the Nth DTD 
defined for this LM. 
If publicly referenced DTD, this is 
the DTD ID and the correlation tag 
to permit access to the record. 
Check Value for entire LM. 



Each load module 1100 also may use DTD 1108 infor- 
mation to provide the information necessary to support 
building methods from a load module. This DTD informa- 
tion contains the definition expressed in a language such as 
SGML for the names and data types of all of the method data 
fields that the load module supports, and the acceptable 
ranges of values that can be placed in the fields. Other DTDs 
may describe the function of the load module 1100 in 
English for inclusion in an electronic contract, for example. 

The next section of load module 1100 is an encrypted 
executable body 1106 that contains one or more blocks of 
encrypted code. Load modules 1100 are preferably coded in 
the "native" instruction set of their execution environment 
for efficiency and compactness. SPU 500 and platform 
providers may provide versions of the standard load mod- 
ules 1100 in order to make their products cooperate with the 
content in distribution mechanisms contemplated by VDE 
100. The preferred embodiment creates and uses native 
mode load modules 1100 in lieu of an interpreted or 
"p-code" solution to optimize the performance of a limited 
resource SPU. However, when sufficient SPE (or HPE) 
resources exist and/or platforms have sufficient resources, 
these other implementation approaches may improve the 
cross platform utility of load module code. 

The following is an example of a field layout for a load 
module DTD 1108: 
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Field Type 



Description 



DID ID Uses Object ID from Private Header. 

Creator ID Site ID of creator of this DTD. 
Type ID Constant. 
DTD ID Unique sequence number for this 

DTD. 

Version number of this DTD. 
Size of DTD block. 



10 



Version ID 
Descriptive DTD Size 
information 

Access and Access tag Tags used to determine if the DTD is 
reference tags Validation tag the correct DTD requested by the SPE. 

Correlation tag Tag used to determine if the caller of 
this DTD has the right to use the DTD. 
DTD Body DTD Data Definition 1 

DTD Data Deftnjtion 2 15 



DTD Data Definition N 

Check Value Check Value for entire DTD record. 
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Some examples of how load modules U00 may use DTDs 
1108 include: 

Increment data element (defined by name in DTD3) value 
in data area DTD4 by value in DTD1 

Set data element (defined by name in DTD3) value in data 25 
area DTD4 to value in DTD3 

Compute atomic element from event in DTD1 from table 
in DTD3 and return in DTD2 

Compute atomic element from event in DTD1 from 30 
equation in DTD3 and return in DTD2 

Create load module from load module creation template 
referenced in DTD3 

Modify load module in DTD3 using content in DTD4 

Destroy load module named in DTD3 35 

Commonly used load modules 1100 may be built into a 
SPU 500 as space permits. VDE processes that use built-in 
load modules 1100 will have significandy better perfor- 
mance than processes that have to find, load and decrypt 
external load modules. The most useful load modules 1100 40 
to build into a SPU might include scaler meters, fixed price 
billing, budgets and load modules for aggregate methods 
that perform these three processes. 

User Data Elements (UDEs) 1200 and Method Data 
Elements (MDEs) 1202 45 

User Data Elements (UDEs) 1200 and Method Data 
Elements (MDEs) 1202 in the preferred embodiment store 
data. There are many types of UDEs 1200 and MDEs 1202 
provided by the preferred embodiment. In the preferred 
embodiment, each of these different types of data structures 50 
shares a common overall format including a common header 
definition and naming scheme. Other UDEs 1200 that share 
this common structure include "local name services records" 
(to be explained shortly) and account information for con- 
necting to other VDE participants. These elements are not 55 
necessarily associated with an individual user, and may 
therefore be considered MDEs 1202. All UDEs 1200 and all 
MDEs 1202 provided by the preferred embodiment may, if 
desired, (as shown in FIG. 16) be stored in a common 
physical table within secure database 610, and database 60 
access processes may commonly be used to access all of 
these different types of data structures. 

In the preferred embodiment, PERCs 808 and user rights 
table records are types of UDE 1200. There are many other 
types of UDEs 1200/MDEs 1202, including for example, 65 
meters, meter trails, budgets, budget trails, and audit trails. 
Different formats for these different types of UDEs/MDEs 



are defined, as described above, by SGML definitions con- 
tained within DTDs 1108, Methods 1000 use these DTDs to 
appropriately access UDEs/MDEs 1200, 1202. 

Secure database 610 stores two types of items: static and 
dynamic. Static data structures and other items are used for 
information that is essentially static information. This 
includes load modules 1100, PERCs 808, and many com- 
ponents of methods. These items are not updated frequently 
and contain expiration dates that can be used to prevent 
"old" copies of the information from being substituted for 
newly received items. These items may be encrypted with a 
site specific secure database file key when they are stored in 
the secure database 610, and then decrypted using that key 
when they are loaded into the SPE. 

Dynamic items are used to support secure items that must 
be updated frequently. The UDEs 1200 of many methods 
must be updated and written out of the SPE 503 after each 
use. Meters and budgets are common examples of this. 
Expiration dates cannot be used effectively to prevent sub- 
stitution of the previous copy of a budget UDE 1200. To 
secure these frequently updated items, a transaction tag is 
generated and included in the encrypted item each time that 
item is updated. A list of all VDE item IDs and the current 
transaction tag for each item is maintained as part of the 
secure database 610. 

FIG. 24 shows an example of a user data element 
("UDE") 1200 provided by the preferred embodiment. As 
shown in FIG. 24, UDE 1200 in the preferred embodiment 
includes a public header 802, a private header 804, and a 
data area 1206. The layout for each of these user data 
elements 1200 is generally defined by an SGML data 
definition contained within a DTD 1108 associated with one 
or more load modules 1100 that operate on the UDE 1200. 

UDEs 1200 are preferably encrypted using a site specific 
key once they are loaded into a site. This site-specific key 
masks a validation tag that may be derived from a crypto - 
graphically strong pseudo-random sequence by the SPE 503 
and updated each time the record is written back to the 
secure database 610. This technique provides reasonable 
assurance that the UDE 1200 has not been tampered with nor 
substituted when it is requested by the system for the next 
use. 

Meters and budgets are perhaps among the most common 
data structures in VDE 100. They are used to count and 
record events, and also to limit events. The data structures 
for each meter and budget are determined by the content 
provider or a distributor/redistributor authorized to change 
the information. Meters and budgets, however, generally 
have common information stored in a common header 
format (e.g., user ID, site ID and related identification 
information). 

The content provider or distributor/redistributor may 
specify data structures for each meter and budget UDE. 
Although these data structures vary depending upon the 
particular application, some are more common than others. 
The following table lists some of the more commonly 
occurring data structures for METER and BUDGET meth- 
ods: 



Field type Format 



Typical 
Use 



Description or 
Use 



Ascending byte, short, long, or Meter/Budget Ascending count 

Use unsigned versions of of uses. 

Counter the same widths 

Descending byte, short, long, or Budget Descending count 
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-continued 







Typical 


Description or 


Field type 


Format 


Use 


Use 


Use 


unsigned versions of 




of permitted use; 


Counter 


the same widths 




eg., remaining 








budget 


Counter/ 


2, 4 or 8 byte integer 


Meter/Budget 


usage limits since 


Limit 


split into two related 




a specific time; 




bytes or words 




generally used in 








compound meter 








data structures. 


Bitmap 


Array bytes 


Meter/Budget 


Bit indicator of 








use or ownership. 


Wide bitmap 


Array of bytes 


Meter/Budget 


Indicator of use 








or ownership that 








may age with 








time. 


Last Use 


time__t 


Meter/Budget 


Date of last use. 


Date 








Start Date 


time_t 


Budget 


Date of first 








allowable use. 


Expiration 


time_t 


Meter/Budget 


Expiration Date. 


Date 








Last Audit 


time_t 


Meter/Budget 


Date of last audit. 


Date 








Next Audit 


time_t 


Meter/Budget 


Date of next 


Date 






required audit. 


Auditor 


VDE ID 


Meter/Budget 


VDE ID of 








authorized 








auditor. 



The information in the table above is not complete or 
comprehensive, but rather is intended to show some 
examples of types of information that may be stored in meter 
and budget related data structures. The actual structure of 
particular meters and budgets is determined by one or more 
DTDs 1108 associated with the load modules 1100 that 
create and manipulate the data structure. A list of data types 
permitted by the DTD interpreter 590 in VDE 100 is 
extensible by properly authorized parties. 

FIG. 25 shows an example of one particularly advanta- 
geous kind of UDE 1200 data area 1206. This data area 1206 
defines a "map" that may be used to record usage informa- 
tion. For example, a meter method 1000 may maintain one 
or more "usage map" data areas 1206, The usage map may 
be a "usage bit map" in the sense that it stores one or more 
bits of information (i.e., a single or multi-dimensional bit 
image) corresponding to each of several types or categories 
of usage. Usage maps are an efficient means for referencing 
prior usage. For example, a usage map data area may be used 
by a meter method 1000 to record all applicable portions of 
information content that the user has paid to use, thus 
supporting a very efficient and flexible means for allowing 
subsequent user usage of the same portions of the informa- 
tion content. This may enable certain VDE related security 
functions such as "contiguousness " "logical relatedness," 
randomization of usage, and other usage types. Usage maps 
may be analyzed for other usage patterns (e.g., quantity 
discounting, or for enabling a user to reaccess information 
content for which the user previously paid for unlimited 
usage). 

The "usage map" concept provided by the preferred 
embodiment may be tied to the concept of "atomic ele- 
ments." In the preferred embodiment, usage of an object 300 
may be metered in terms of "atomic elements." In the 
preferred embodiment, an "atomic element" in the metering 
context defines a unit of usage that is "sufficiently signifi- 
cant" to be recorded in a meter. The definition of what 
constitutes an "atomic element" is determined by the creator 
of an object 300. For instance, a "byte" of information 
content contained in an object 300 could be defined as an 
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"atomic element," or a record of a database could be defined 
as an "atomic element," or each chapter of an electronically 
published book could be defined as an "atomic element." 
An object 300 can have multiple sets of overlapping 

5 atomic elements. For example, an access to any database in 
a plurality of databases may be defined as an "atomic 
element." Simultaneously, an access to any record, field of 
records, sectors of informations, and/or bytes contained in 
any of the plurality of databases might also be defined as an 

10 "atomic element." In an electronically published newspaper, 
each hundred words of an article could be defined as an 
"atomic element," while articles of more than a certain 
length could be defined as another set of "atomic elements." 
Some portions of a newspaper (e.g., advertisements, the 

15 classified section, etc.) might not be mapped into an atomic 
element. 

The preferred embodiment provides an essentially 
unbounded ability for the object creator to define atomic 
element types. Such atomic element definitions may be very 

20 flexible to accommodate a wide variety of different content 
usage. Some examples of atomic element types supported by 
the preferred embodiment include bytes, records, files, 
sectors, objects, a quantity of bytes, contiguous or relatively 
contiguous bytes (or other predefined unit types), logically 

25 related bytes containing content that has some logical rela- 
tionship by topic, location or other user specifiable logic of 
relationship, etc. Content creators preferably may flexibly 
define other types of atomic elements. 

The preferred embodiment of the present invention pro- 

30 vides EVENT methods to provide a mapping between usage 
events and atomic elements. Generally, there may be an 
EVENT method for each different set of atomic elements 
defined for an object 300. In many cases, an object 300 will 
have at least one type of atomic element for metering 

35 relating to billing, and at least one other atomic element type 
for non-billing related metering (e.g., used to, for example, 
detect fraud, bill advertisers, and/or collect data on end user 
usage activities). 

In the preferred embodiment, each EVENT method in a 

40 usage related context performs two functions: (1) it maps an 
accessed event into a set of zero or more atomic elements, 
and (2) it provides information to one or more METER 
methods for metering object usage. The definition used to 
define this mapping between access events and atomic 

45 elements may be in the form of a mathematical definition, a 
table, a load module, etc. When an EVENT method maps an 
access request into "zero" atomic elements, a user accessed 
event is not mapped into any atomic element based on the 
particular atomic element definition that applies. This can 

50 be, for example, the object owner is not interested in 
metering usage based on such accesses (e.g., because the 
object owner deems such accesses to be insignificant from a 
metering standpoint). 
A "usage map" may employ a "bit map image" for storage 

55 of usage history information in a highly efficient manner. 
Individual storage elements in a usage map may correspond 
to atomic elements. Different elements within a usage map 
may correspond to different atomic elements (e.g., one map 
element may correspond to number of bytes read, another 

60 map element may correspond to whether or not a particular 
chapter was opened, and yet another map element may 
correspond to some other usage event). 

One of the characteristics of a usage map provided by the 
preferred embodiment of the present invention is that the 

65 significance of a map element is specified, at least in part, by 
the position of the element within the usage map. Thus, in 
a usage map provided by the preferred embodiment, the 
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information indicated or encoded by a map element is a groups of users might employ multiple sessions to extract 

function of its position (either physically or logically) within content in a manner which does not violate contiguousness, 

the map structure. As one simple example, a usage map for logical relatedness or quantity limitations, but which nev- 

a twelve-chapter novel could consist of twelve elements, one ertheless enables reconstruction of a material portion or all 

for each chapter of the novel. When the user opens the first 5 of a given, valuable unit of content. Usage maps can be 

chapter, one or more bits within the element corresponding analyzed to determine other patterns of usage for pricing 

to the first chapter could be changed in value (e.g., set to such as, for example, quantity discounting after usage of a 

"one"). In this simple example where the owner of the certain quantity of any or certain atomic units, or for 

content object containing the novel was interested only in enabling a user to reaccess an object for which the user 

metering which chapters had been opened by the user, the 10 previously paid for unlimited accesses (or unlimited 

usage map element corresponding to a chapter could be set accesses over a certain time duration). Other useful analyses 

to "one" the first time the user opened that corresponding might include discounting for a given atomic unit for a 

chapter, and could remain "one" no matter how many plurality of uses. 

additional times the user opened the chapter. The object A further example of a map meter includes storing a 

owner or other interested VDE participant would be able to 15 record of all applicable atomic elements that the user has 

rapidly and efficiently tell which chapters) had been opened paid to use (or alternatively, has been metered as having 

by the user simply by examining the compact usage map to used, though payment may not yet have been required or 

determine which elements were set to "one." made). Such a usage map would support a very efficient and 

Suppose that the content object owner wanted to know flexible way to allow subsequent user usage of the same 

how many times the user had opened each chapter of the 20 atomic elements. 

novel. In this case, the usage map might comprise, for a A further usage map could be maintained to detect fraudu- 

twelve-chapter novel, twelve elements each of which has a lent usage of the same object. For example, the object might 

one-to-one correspondence with a different one of the twelve be stored in such a way that sequential access of long blocks 

chapters of the novel. Each time a user opens a particular should never occur. A METER method could then record all 

chapter, the corresponding METER method might incre- 25 applicable atomic elements accesses during, for example, 

ment the value contained in the corresponding usage map any specified increment of time, such as ten minutes, an 

element. In this way, an account could be readily maintained hour, a day, a month, a year, or other time duration). The 

for each of the chapters of the novel. usage map could be analyzed at the end of the specified time 

The position of elements within a usage map may encode increment to check for an excessively long contiguous set of 

a multi- variable function. For example, the elements within 30 accessed blocks, and/or could be analyzed at the initiation of 

a usage map may be arranged in a two-dimensional array as each access to applicable atomic elements. After each time 

shown in FIG. 25B. Different array coordinates could cor- duration based analysis, if no fraudulent use is detected, the 

respond to independent variables such as, for example, usage map could be cleared (or partially cleared) and the 

atomic elements and time. Suppose, as an example, that a mapping process could begin in whole or in part anew. If a 

content object owner distributes an object containing a 35 fraudulent use pattern is suspected or detected, that infor- 

collection of audio recordings. Assume further that the mation might be recorded and the use of the object could be 

content object owner wants to track the number of times the halted. For example, the user might be required to contact a 

user listens to each recording within the collection, and also content provider who might then further analyze the usage 

wants to track usage based on month of the year. Thus, information to determine whether or not further access 

assume that the content object owner wishes to know how 40 should be permitted. 

many times the user during the month of January listened to FIG. 25c shows a particular type of "wide bit map" usage 

each of the recordings on a recording-by-recording basis, record 1206 wherein each entry in the usage record corre- 

similarly wants to know this same information for the month sponds to usage during a particular time period (e.g., current 

of February, March, etc. In this case, the usage map (see month usage, last month's usage, usage in the month before 

FIG. 25B) might be defined as a two-dimensional array of 45 last, etc.). The usage record shown thus comprises an array 

elements. One dimension of the array might encode audio of "flags" or fields 1206, each element in the array being 

recording number. The other dimension of the array might used to indicate usage in a different time period in this 

encode month of the year. During the month of January, the particular example. When a time period ends, all elements 

corresponding METER method would increment elements 1206 in the array may be shifted one position, and thus usage 

in the array in the "January" column of the array, selecting 50 information (or the purchase of user access rights) over a 

which element to increment as a function of recording series of time periods can be reflected by a series of 

number. When January comes to an end, the METER successive array elements. In the specific example shown in 

method might cease writing into the array elements in the FIG. 25c, the entire wide array 1206 is shifted by one array 

January column, and instead write values into a further set position each month, with the oldest array element being 

of February array elements— once again selecting the par- 55 deleted and the new array element being "turned" in a new 

ticular array element in this column as a function of record- array map corresponding to the current time period. In this 

ing number. This concept may be extended to N dimensions example, record 1302 tracks usage access rights and/or other 

encoding N different variables. usage related activities during the present calendar month as 

Usage map meters are thus an efficient means for refer- well for the five immediately prior calendar months. Cor- 

encing prior usage. They may be used to enable certain VDE 60 responding billing and/or billing method 406 may inspect 

related security functions such as testing for contiguousness the map, determine usage as related to billing and/or security 

(including relative contiguousness), logical relatedness monitoring for current usage based on a formula that 

(including relative logical relatedness), usage employs the usage data stored in the record, and updates the 

randomization, and other usage patterns. For example, the wide record to indicate the applicable array elements for 

degree or character of the "randomness" of content usage by 65 which usage occurred or the like. A wide bit map may also 

a user might serve as a potential indicator of attempts to be used for many other purposes such as maintaining an 

circumvent VDE content budget limitations. A user or element by element count of usage, or the contiguousness, 
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relatedness, etc. function described above, or some combi- 
nation of functionality. 

Audit trail maps may be generated at any frequency 
determined by control, meter, budget and billing methods 
and load modules associated with those methods. Audit 
trails have a similar structure to meters and budgets and they 
may contain user specific information in addition to infor- 
mation about the usage event that caused them to be created. 
Like meters and budgets, audit trails have a dynamic format 
that is defined by the content provider or their authorized 
designee, and share the basic element types for meters and 
budgets shown in the table above. In addition to these types, 
the following table lists some examples of other significant 
data fields that may be found in audit trails: 



10 



Field type 


Format 


Typical Use 


Description of Use 


Use Event ID 


unsigned long 


Meter/Budget/ 


Event ID that started a 






Billing 


processing sequence. 


Internal 


unsigned long 


Meter/Budget/ 


Transaction number to 


Sequence 




Billing 


help detect audits that 


Number 






have been tampered 








with. 


Atomic 


Unsigned 


Meter/Billing 


Atomic elements) and 


Element(s) 


Integers) of 




ID of object that was 


& Object ID 


appropriate 




used. 




width 






Personal User 


Character or 


Budget/Billing 


Personal information 


information 


other 




about user. 




information 






Use Date/Time 


time_t 


Meter/Budgel/ 


Date/time of use. 






Billing 




Site ID/User 


VDE ID 


Meter/Budget/ 


VDE ID of user. 






Billing 





20 



25 



30 



Audit trail records may be automatically combined into 
single records to conserve header space. The combination 
process may, for example, occur under control of a load 35 
module that creates individual audit trail records. 

Permissions Record Overview 

FIG. 16 also shows that PERCs 808 may be stored as part 
of secure database 610. Permissions records ("PERCs") 808 
are at the highest level of the data driven control hierarchy 40 
provided by the preferred embodiment of VDE 100. 
Basically, there is at least one PERC 808 that corresponds to 
each information and/or transactional content distributed by 
VDE 100. Thus, at least one PERC 808 exists for each VDE 
object 300 in the preferred embodiment. Some objects may 45 
have multiple corresponding PERCs 808. PERC 808 con- 
trols how access and/or manipulation permissions are dis- 
tributed and/or how content and/or other information may 
otherwise be used. PERC 808 also specifies the "rights" of 
each VDE participant in and to the content and/or other 50 
information. 

In the preferred embodiment, no end user may use or 
access a VDE object unless a permissions record 808 has 
been delivered to the end user. As discussed above, a PERC 
808 may be delivered as part of a traveling object 860 or it 55 
may be delivered separately (for example, within an admin- 
istrative object). An electronic appliance 600 may not access 
an object unless a corresponding PERC 808 is present, and 
may only use the object and related information as permitted 
by the control structures contained within the PERC. 

Briefly, the PERC 808 stores information concerning the 
methods, method options, decryption keys and rights with 
respect to a corresponding VDE object 300. 

PERC 808 includes control structures that define high 
level categories or classifications of operations. These high 65 
level categories are referred to as "rights." The "right" 
control structures, in turn, provide internal control structures 
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that reference "methods" 1000. The internal structure of 
preferred embodiment PERC 808 organizes the "methods" 
that are required to perform each allowable operation on an 
object or associated control structure (including operations 
performed on the PERC itself). For example, PERC 808 
contains decryption keys for the object, and usage of the 
keys is controlled by the methods that are required by the 
PERC for performing operations associated with the exer- 
cise of a "right." 

PERC 808 for an object is typically created when the 
object is created, and future substantive modifications of a 
PERC, if allowed, are controlled by methods associated with 
operations using the distribution right(s) defined by the same 
(or different) PERC. 

FIG. 22 shows the internal structures present in an 
example of a PERC 808 provided by the preferred embodi- 
ment. All of the structures shown represent (or reference) 
collections of methods required to process a corresponding 
object in some specific way. PERCs 808 are organized as a 
hierarchical structure, and the basic elements of the hierar- 
chy are as follows: 
"rights" records 906 
"control sets" 914 

"required method" records 920 and 
"required method options" 924. 
There are other elements that may be included in a PERC 
808 hierarchy that describe rules and the rule options to 
support the negotiation of rule sets and control information 
for smart objects and for the protection of a user's personal 
information by a privacy filter. These alternate elements may 
include: 

optional rights records 
optional control sets 
optional method records 
permitted rights records 
permitted rights control sets 
permitted method records 
required DTD descriptions 
optional DTD descriptions 
permitted DTD descriptions 
These alternate fields can control other processes that may, 
in part, base negotiations or decisions regarding their opera- 
tion on the contents of these fields. Rights negotiation, smart 
object control information, and related processes can use 
these fields for more precise control of their operation. 

The PERC 808 shown in FIG. 26 includes a PERC header 
900, a CS0 ("control set 0") 902, private body keys 904, and 
one or more rights sub-records 906. Control set 0 902 in the 
preferred embodiment contains information that is common 
to one or more "rights" associated with an object 300. For 
example, a particular "event" method or methods might be 
the same for usage rights, extraction rights and/or other 
rights. In that case, "control set 0" 902 may reference this 
event that is common across multiple "rights." The provision 
of "control set 0" 902 is actually an optimization, since it 
would be possible to store different instances of a 
commonly -used event within each of plural "rights" records 
906 of a PERC 808. 

Each rights record 906 defines a different "right" corre- 
sponding to an object. A "right" record 906 is the highest 
level of organization present in PERC 808. There can be 
several different rights in a PERC 808. A "right" represents 
a major functional partitioning desired by a participant of the 
basic architecture of VDE 100. For example, the right to use 
an object and the right to distribute rights to use an object are 
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major functional groupings within VDE 100. Some 
examples of possible rights include access to content, per- 
mission to distribute rights to access content, the ability to 
read and process audit trails related to content and/or control 
structures, the right to perform transactions that may or may 5 
not be related to content and/or related control structures 
(such as banking transactions, catalog purchases, the col- 
lection of taxes, EDI transactions, and such), and the ability 
to change some or all of the internal structure of PERCs 
created for distribution to other users. PERC 808 contains a 10 
rights record 906 for each type of right to object access^se 
the PERC grants. 

Normally, for VDE end users, the most frequently granted 
right is a usage right. Other types of rights include the 
"extraction right," the "audit right" for accessing audit trail 15 
information of end users, and a "distribution right" to 
distribute an object. Each of these different types of rights 
may be embodied in a different rights record 906 (or 
alternatively, different PERCs 808 corresponding to an 
object may be used to grant different rights). 20 

Each rights record 906 includes a rights record header 
908, a CSR ("control set for righf ') 910, one or more "right 
keys" 912, and one or more "control sets" 914. Each "rights" 
record 906 contains one or more control sets 914 that are 
either required or selectable options to control an object in 25 
the exercise of that "right." Thus, at the next level, inside of 
a "right" 906, are control sets 914. Control sets 914, in turn, 
each includes a control set header 916, a control method 918, 
and one or more required methods records 920. Required 
methods records 920, in turn, each includes a required 30 
method header 922 and one or more required method 
options 924. 

Control sets 914 exist in two types in VDE 100: common 
required control sets which are given designations "control 
set 0" or "control set for right," and a set of control set 35 
options. "Control set 0" 902 contains a list of required 
methods that are common to all control set options, so that 
the common required methods do not have to be duplicated 
in each control set option. A "control set for right" ("CSR") 
910 contains a similar list for control sets within a given 40 
right. "Control set 0" and any "control sets for rights" are 
thus, as mentioned above, optimizations; the same function- 
ality for the control sets can be accomplished by listing all 
the common required methods in each control set option and 
omitting "control set 0" and any "control sets for rights." 45 

One of the control set options, "control set 0" and the 
appropriate "control set for right" together form a complete 
control set necessary to exercise a right. 

Each control set option contains a list of required methods 
1000 and represents a different way the right may be 50 
exercised. Only one of the possible complete control sets 
914 is used at any one time to exercise a right in the 
preferred embodiment. 

Each control set 914 contains as many required methods 
records 920 as necessary to satisfy all of the requirements of 55 
the creators and/or distributors for the exercise of a right. 
Multiple ways a right may be exercised, or multiple control 
sets that govern how a given right is exercised, are both 
supported. As an example, a single control set 914 might 
require multiple meter and budget methods for reading the 60 
object's content, and also require different meter and budget 
methods for printing an object's content. Both reading and 
printing an object's content can be controlled in a single 
control set 914. 

Alternatively, two different control set options could 65 
support reading an object's content by using one control set 
option to support metering and budgeting the number of 
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bytes read, and the other control set option to support 
metering and budgeting the number of paragraphs read. One 
or the other of these options would be active at a time. 

Typically, each control set 914 will reference a set of 
related methods, and thus different control sets can offer a 
different set of method options. For example, one control set 
914 may represent one distinct kind of metering 
methodology, and another control set may represent another, 
entirely different distinct metering methodology. 

At the next level inside a control set 914 are the required 
methods records 920. Methods records 920 contain or ref- 
erence methods 1000 in the preferred embodiment. Methods 
1000 are a collection of "events," references to load modules 
associated with these events, static data, and references to a 
secure database 610 for automatic retrieval of any other 
separately deliverable data elements that may be required for 
processing events (e.g., UDEs). A control set 914 contains a 
list of required methods that must be used to exercise a 
specific right (i.e., process events associated with a right). A 
required method record 920 listed in a control set 914 
indicates that a method must exist to exercise the right that 
the control set supports. The required methods may refer- 
ence "load modules" 1100 to be discussed below. Briefly, 
load modules 1100 are pieces of executable code that may be 
used to carry out required methods. 

Each control set 914 may have a control method record 
918 as one of its required methods. The referenced control 
method may define the relationships between some or all of 
the various methods 1000 defined by a control set 906. For 
example, a control method may indicate which required 
methods are functionally grouped together to process par- 
ticular events, and the order for processing the required 
methods. Thus, a control method may specify that required 
method referenced by record 920(a)(l)(i) is the first to be 
called and then its output is to go to required method 
referenced by record 920(a)(1)(a) and so on. In this way, a 
meter method may be tied to one or more billing methods 
and then the billing methods may be individually tied to 
different budget methods, etc. 

Required method records 920 specify one or more 
required method options 924. Required method options are 
the lowest level of control structure in a preferred embodi- 
ment PERC 808. By parameterizing the required methods 
and specifying the required method options 924 indepen- 
dently of the required methods, it becomes possible to reuse 
required methods in many different circumstances. 

For example, a required method record 920 may indicate 
that an actual budget method ID must be chosen from the list 
of budget method IDs in the required method option list for 
that required method. Required method record 920 in this 
case does not contain any method IDs for information about 
the type of method required, it only indicates that a method 
is required. Required method option 924 contains the 
method ID of the method to be used if this required method 
option is selected. As a further optimization, an actual 
method ID may be stored if only one option exists for a 
specific required method. This allows the size of this data 
structure to be decreased. 

PERC 808 also contains the fundamental decryption keys 
for an object 300, and any other keys used with "rights" (for 
encoding and/or decoding audit trails, for example). It may 
contain the keys for the object content or keys to decrypt 
portions of the object that contain other keys that then can 
be used to decrypt the content of the object. Usage of the 
keys is controlled by the control sets 914 in the same "right" 
906 within PERC 808. 

In more detail, FIG. 26 shows PERC 808 as including 
private body keys 904, and right keys 912. Private body keys 
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904 are used to decrypt information contained within a a method ID field 968 specifying a method ID (e.g., 

private body 806 of a corresponding VDE object 300. Such type/owner/class/instance) 

information may include, for example, methods 1000, load a correlation tag field 970 specifying a correlation tag for 

modules 1100 and/or UDEs 1200, for example. Right keys correlating with the method specified in field 968 

912 are keys used to exercise a right in the preferred 5 aQ acces& field 9?2 ^ ^ „ ^ ss t t o control 

embodiment. Such right keys 912 may include, for example, modification of this record 

decryption keys that enable a method specified by PERC , , 

808 to decrypt content for release by a VDE node to an end a method-specific attributes field 974 

user. These right keys 912 are, in the preferred embodiment, a data area 976 and 

unique to an object 300. Their usage is preferably controlled 10 a check value field 978 for validation purposes 

by budgets in the preferred embodiment. In this example of PERC 808 also includes one or more 

Detailed Example of a PERC 808 rights records 906, and an overall check value field 980. 

FIGS. 26A and 26B show one example of a preferred FIG. 23fc is an example of one of right records 906 shown 

embodiment PERC 808. In this example, PERC header 900 in FIG. 16a. In this particular example, rights record 906a 

includes: 15 includes a rights record header 908 comprising: 

a site record number 926, a length field 982 specifying the length of the rights key 

a field 928 specifying the length of the private body key block 912 

Jj IT* block, a length field 984 specifying the length of the rights record 

' a field 930 specifying the length of the PERC, 908 

an expiration date/time field 932 specifying the expiration an expiration date/time field 986 specifying the expiration 

date and/or time for the PERC, date ««Vor for me ng^s rec °rd 

a last modification date/time field 934 specifying the last a right ID field 988 identifying a right 

date and/or time the PERC 808 was modified, a number field 990 specifying the number of control sets 

the original distributor ID field 936 that specifies who ^ 914 within the rights record 906, and 

originally distributed the PERC and/or corresponding an access tag field 992 specifying an access tag to control 

object, modification of the right record, 

a last distributor field 938 that specifies who was the last This example of rights record 906 includes: 

distributor of the PERC and/or the object, a control set for this right (CSR) 910 

an object ID field 940 identifying the corresponding VDE a rights key block 912 

object 300, one or more control sets 914, and 

a field 942 that specifies the class and/or type of PERC a check value field 994. 

and/or the instance ID for the record class to differen- Object Registry 

date the PERCs of the same type that may differ in their 3S Referring once again to FIG. 16, secure database 610 

particulars, provides data structures that support a "lookup" mechanism 

a field 944 specifying the number of "rights" sub-records for "registered" objects. This "lookup" mechanism permits 

906 within the PERC, and electronic appliance 600 to associate, in a secure way, VDE 

a validation tag 948. objects 300 with PERCs 808, methods 1000 and load 

ftp 1 The PERC 808 shown in FIGS. 26a, 26b also has private 40 modules 1100. In the preferred embodiment, this lookup 

body keys stored in a private body key block 950. mechanism is based in part on data structures contained 

This PERC 808 includes a control set 0 sub-record 914(0) within object registry 450. 

that may be used commonly by all of rights 906 within the In one embodiment, object registry 450 includes the 

PERC. This control set 0 record 914(0) may include the following tables: 

following fields: 45 a n object registration table 460; 

a length field 952 specifying the length of the control set a subject table 462; 

0 record a User Rights Table ("URT") 464; 

a field 954 specifying the number of required method an Administrative Event Log 442; 

records 920 within the control set 5Q a s hi ppmg table 444; and 

an access tag field 956 specifying an access tag to control a receiving table 446. 

modification of the record and Object registry 460 in the example embodiment is a 

one or more required method records 920. database of information concerning registered VDE objects 

Each required method record 920, in turn may include: 300 and the rights of users and user groups with regard to 

a length field 958 specifying the length of the required 55 those objects. When electronic appliance 600 receives an 

method record object 300 containing a new budget or load module 1100, the 

a field 960 specifying the number of method option electronic appliance usually needs to add the information 

records within the required method record 920 contained by the object to secure database 610. Moreover, 

* £ ij ns>% r • 4 , . t wnen new object 300 arrives at an electronic 

an access tag field 962 specifying an access tag to control „ ,. ^ nn , , . . (( • 

A . a 5 f * t «j j 60 appliance 600, the electronic appliance must "register" the 

modification of the record and ff , .... ... . , A /gZ i« - . & , 

object within object registry 450 so that it can be accessed, 

one or more method option records 924. Xhe lists and rccords fof a ncw objcct 300 arc built in the 

Each method option sub-record 924 may include: preferred embodiment when the object is "registered" by the 

a length field 964 specifying the length of the method electronic appliance 600. The information for the object may 

option record 65 be obtained from the object's encrypted private header, 

a length field 966 specifying the length of the data area (if object body, and encrypted name services record. This 

any) corresponding to the method option record information may be extracted or derived from the object 300 
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by SPE 503, and then stored within secure database 610 as 
encrypted records. 

In one embodiment, object registration table 460 includes 
information identifying objects within object storage 
(repository) 728, These VDE objects 300 stored within 5 
object storage 728 are not, in the example embodiment, 
necessarily part of secure database 610 since the objects 
typically incorporate their own security (as necessary and 
required) and are maintained using different mechanisms 
than the ones used to maintain the secure database. Even 10 
though VDE objects 300 may not strictly be part of secure 
database 610, object registry 450 (and in particular, object 
registration table 460) refers to the objects and thus "incor- 
porates them by reference" into the secure database. In the 
preferred embodiment, an electronic appliance 600 may be 15 
disabled from using any VDE object 300 that has not been 
appropriately registered with a corresponding registration 
record stored within object registration table 460. 

Subject table 462 in the example embodiment establishes 
correspondence between objects referred to by object reg- 20 
istration table 460 and users (or groups of users) of elec- 
tronic appliance 600. Subject table 462 provides many of the 
attributes of an access control list ("ACL"), as will be 
explained below. 

User rights table 464 in the example embodiment pro- 25 
vides permissioning and other information specific to par- 
ticular users or groups of users and object combinations set 
forth in subject table 462. In the example embodiment, 
permissions records 808 (also shown in FIG. 16 and being 
stored within secure database 610) may provide a universe 30 
of permissioning for a particular object-user combination. 
Records within user rights table 464 may specify a sub-set 
of this permissioning universe based on, for example, 
choices made by users during interaction at time of object 
registration. 35 

Administrative event log 442, shipping table 444, and 
receiving table 446 provide information about receipts and 
deliveries of VDE objects 300. These data structures keep 
track of administrative objects sent or received by electronic 
appliance 600 including, for example, the purpose and 40 
actions of the administrative objects in summary and 
detailed form. Briefly, shipping table 444 incudes a shipping 
record for each administrative object sent (or scheduled to 
be sent) by electronic appliance 600 to another VDE par- 
ticipant. Receiving table 446 in the preferred embodiment 45 
includes a receiving record for each administrative object 
received (or scheduled to be received) by electronic appli- 
ance 600. Administrative event log 442 includes an event log 
record for each shipped and each received administrative 
object, and may include details concerning each distinct 50 
event specified by received administrative objects. 

Administrative Object Shipping and Receiving 

FIG. 27 is an example of a detailed format for a shipping 
table 444. In the preferred embodiment, shipping table 444 
includes a header 444A and any number of shipping records 55 
445. Header 444A includes information used to maintain 
shipping table 444. Each shipping record 445 within ship- 
ping table 444 provides details concerning a shipping event 
(i.e., either a completed shipment of an administrative object 
to another VDE participant, or a scheduled shipment of an 60 
administrative object). 

In the example embodiment of the secure database 610, 
shipping table header 444A may include a site record 
number 444A(1), a user (or group) ID 444A(2), a series of 
reference fields 444A(3)-444A(6), validation tags 444A(7) 65 
-444A(8), and a check value field 444A(9). The fields 
444A(3)-444A(6) reference certain recent IDs that desig- 
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nate lists of shipping records 445 within shipping table 444. 
For example, field 444A(3) may reference to a "first" 
shipping record representing a completed outgoing shipment 
of an administrative object, and field 444A(4) may reference 
to a "last" shipping record representing a completed outgo- 
ing shipment of an administrative object. In this example, 
"first" and "last" may, if desired, refer to time or order of 
shipment as one example. Similarly, fields 444A(5) and 
444A(6) may reference to "first" and "last" shipping records 
for scheduled outgoing shipments. Validation tag 444A(7) 
may provide validation from a name services record within 
name services record table 452 associated with the user 
(group) ID in the header. This permits access from the 
shipping record back to the name services record that 
describes the sender of the object described by the shipping 
records. Validation tag 444A(8) provides validation for a 
"first" outgoing shipping record referenced by one or more 
of pointers 444A(3)-444A(6). Other validation tags may be 
provided for validation of scheduled shipping record(s). 

Shipping record 444(1) shown includes a site record 
number 445(1)(A), It also includes first and last scheduled 
shipment date/times 445(1)(B), 445(1)(C) providing a win- 
dow of time used for scheduling administrative object 
shipments. Field 445(1)(D) may specify an actual date/time 
of a completed shipment of an administrative object. Field 
445(1)(E) provides an ID of an administrative object 
shipped or to be shipped, and thus identifies which admin- 
istrative object within object storage 728 pertains to this 
particular shipping record. A reference field 445(1)(G) ref- 
erences a name services record within name services record 
table 452 specifying the actual or intended recipient of the 
administrative object shipped or to be shipped. This infor- 
mation within name services record table 452 may, for 
example, provide routing information sufficient to permit 
outgoing administrative objects manager 754 shown in FIG. 
12 to inform object switch 734 to ship the administrative 
object to the intended recipient. A field 445(1)(H) may 
specify (e.g., using a series of bit flags) the purpose of the 
administrative object shipment, and a field 445(1)(I) may 
specify the status of the shipment. Reference fields 445(1) 
(J), 445(1)(K) may reference "previous" and "next" ship- 
ping records 445 in a linked list (in the preferred 
embodiment, there may be two linked lists, one for com- 
pleted shipping records and the other for scheduled shipping 
records). Fields 445(1)(L)-445(1)(P) may provide valida- 
tion tags respectively from header 444A, to a record within 
administrative event log 442 pointed to by pointer 445(1) 

(F) ; to the name services record referenced by field 445(1) 

(G) ; from the previous record referenced by 445(1)(J); and 
to the next record referenced by field 445(1)(K). A check 
value field 445(1)(Q) may be used for validating shipping 
record 445. 

FIG. 28 shows an example of one possible detailed format 
for a receiving table 446. In one embodiment, receiving 
table 446 has a structure that is similar to the structure of the 
shipping table 444 shown in FIG. 27. Thus, for example, 
receiving table 446 may include a header 446a and a 
plurality of receiving records 447, each receiving record 
including details about a particular reception or scheduled 
reception of an administrative object. Receiving table 446 
may include two linked lists, one for completed receptions 
and another for schedule receptions. Receiving table records 
447 may each reference an entry within name services 
record table 452 specifying an administrative object sender, 
and may each point to an entry within administrative event 
log 442. Receiving records 447 may also include additional 
details about scheduled and/or completed reception (e.g., 
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scheduled or actual date/time of reception, purpose of recep- 
tion and status of reception), and they may each include 
validation tags for validating references to other secure 
database records. 

FIG. 29 shows an example of a detailed format for an 
administrative event log 442. In the preferred embodiment, 
administrative event log 442 includes an event log record 
442(1) . , . 442(N) for each shipped administrative object 
and for each received administrative object. Each adminis- 
trative event log record may include a header 443a and from 
1 to N sub-records 442(J)(1) . . . 442(J)(N). In the preferred 
embodiment, header 443a may include a site record number 
field 443 A(l), a record length field 443 A(2), an administra- 
tive object ID field 443 A(3), a field 443 A(4) specifying a 
number of events, a validation tag 443A(5) from shipping 
table 444 or receiving table 446, and a check sum field 
443A(6). The number of events specified in field 443A(4) 
corresponds to the number of sub-records 442(J)(1) . . . 
442(J)(N) within the administrative event log record 442(J). 
Each of these sub-records specifies information about a 
particular "event" affected or corresponding to the admin- 
istrative object specified within field 443(A)(3). Adminis- 
trative events are retained in the administrative event log 
442 to permit the reconstruction (and preparation for con- 
struction or processing) of the administrative objects that 
have been sent from or received by the system. This permits 
lost administrative objects to be reconstructed at a later time. 

Each sub-record may include a sub-record length field 
442(J)(l)(a), a data area length field 442(J)(1)(6), an event 
ID field 442(J)(l)(c), a record type field 442(J)(1)(<0, a 
record ID field 442(J)(l)(e), a data area field 442(J)(l)(f), 
and a check value field 442(J)(l)(g). The data area 442(J) 
(l)(f) may be used to indicate which information within 
secure database 610 is affected by the event specified in the 
event ID field 442(J)(l)(c), or what new secure database 
item(s) were added, and may also specify the outcome of the 
event. 

The object registration table 460 in the preferred embodi- 
ment includes a record corresponding to each VDE object 
300 within object storage (repository) 728. When a new 
object arrives or is detected (e.g., by redirector 684), a 
preferred embodiment electronic appliance 600 "registers" 
the object by creating an appropriate object registration 
record and storing it in the object registration table 460. In 
the preferred embodiment, the object registration table 
stores information that is user-independent, and depends 
only on the objects that are registered at a given VDE 
electronic appliance 600. Registration activities are typically 
managed by a REGISTER method associated with an object. 

In the example, subject table 462 associates users (or 
groups of users) with registered objects. The example sub- 
ject table 462 performs the function of an access control list 
by specifying which users are authorized to access which 
registered VDE objects 300. 

As described above, secure database 610 stores at least 
one PERC 808 corresponding to each registered VDE object 
300. PERCS 808 specify a set of rights that may be exercised 
to use or access the corresponding VDE object 300. The 
preferred embodiment allows user to "customize'* their 
access rights by selecting a subset of rights authorized by a 
corresponding PERC 808 and/or by specifying parameters 
or choices that correspond to some or all of the rights 
granted by PERC 808. These user choices are set forth in a 
user rights table 464 in the preferred embodiment. User 
rights table (URT) 464 includes URT records, each of which 
corresponds to a user (or group of users). Each of these URT 
records specifies user choices for a corresponding VDE 
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object 300. These user choices may, either independently or 
in combination with a PERC 808, reference one or more 
methods 1000 for exercising the rights granted to the user by 
the PERC 808 in a way specified by the choices contained 
5 within the URT record. 

FIG. 30 shows an example of how these various tables 
may interact with one another to provide a secure database 
lookup mechanism. FIG. 30 shows object registration table 
460 as having a plurality of object registration records 
10 460(1), 460(2), .... These records correspond to VDE 
objects 300(1), 300(2), . . . stored within object repository 
728. FIG. 31 shows an example format for an object 
registration record 460 provided by the preferred embodi- 
ment. Object registration record 460(N) may include the 
15 following fields: 

site record number field 466(1) 

object type field 466(2) 

creator ID field 466(3) 
2Q object ID field 466(4) 

a reference field 466(5) that references subject table 462 

an attribute field 466(6) 

a minimum registration interval field 466(7) 

a tag 466(8) to a subject table record, and 
25 a check value field 466(9). 

The site record number field 466(1) specifies the site 
record number for this object registration record 460(N). In 
one embodiment of secure database 610, each record stored 
within the secure database is identified by a site record 
30 number. This site record number may be used as part of a 
database lookup process in order to keep track of all of the 
records within the secure database 610. 

Object type field 466(2) may specify the type of registered 
VDE object 300 (e.g., a content object, an administrative 
35 object, etc.). 

Creator ID field 466(3) in the example may identify the 
creator of the corresponding VDE object 300. 

Object ID field 466(4) in the example uniquely identifies 
the registered VDE object 300. 
40 Reference field 466(5) in the preferred embodiment iden- 
tifies a record within the subject table 462. Through use of 
this reference, electronic appliance 600 may determine all 
users (or user groups) listed in subject table 462 authorized 
to access the corresponding VDE object 300. Tag 466(8) is 
45 used to validate that the subject table records accessed using 
field 466(5) is the proper record to be used with the object 
registration record 460(N). 

Attribute field 466(6) may store one or more attributes or 
attribute flags corresponding to VDE object 300. 
50 Minimum registration interval field 466(7) may specify 
how often the end user may re-register as a user of the VDE 
object 300 with a clearinghouse service, VDE administrator, 
or VDE provider. One reason to prevent frequent 
re -registration is to foreclose users from reusing budget 
55 quantities in traveling objects until a specified amount of 
time has elapsed. The minimum registration interval field 
466(7) may be left unused when the object owner does not 
wish to restrict re-registration. 

Check value field 466(9) contains validation information 
60 used for detecting corruption or modification of record 
460(N) to ensure security and integrity of the record. In the 
preferred embodiment, many or all of the fields within 
record 460(N) (as with other records within the secure 
database 610) may be fully or partially encrypted and/or 
65 contain fields that are stored redundantly in each record 
(once in unencrypted form and once in encrypted form). 
Encrypted and unencrypted versions of the same fields may 
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be cross checked at various times to detect corruption or 
modification of the records. 

As mentioned above, reference field 466(5) references 
subject table 462, and in particular, references one or more 
user/object records 460(M) within the subject table. FIG. 32 
shows an example of a format for a user/object record 
462(M) provided by the example. Record 462(M) may 
include a header 468 and a subject record portion 470. 
Header 468 may include a field 468(6) referencing a "first" 
subject record 470 contained within the subject registration 
table 462. This "first" subject record 470(1) may, in turn, 
include a reference field 470(5) that references a "next" 
subject record 470(2) within the subject registration table 
462, and so on. This "linked list" structure permits a single 
object registration record 460(N) to reference to from one to 
N subject records 470. 

Subject registration table header 468 in the example 
includes a site record number field 468(1) that may uniquely 
identify the header as a record within secure database 610. 
Header 468 may also include a creator ID field 468(2) that 
may be a copy of the content of the object registration table 
creator ID field 466(3). Similarly, subject registration table 
header 468 may include an object ID field 468(5) that may 
be a copy of object ID field 466(4) within object registration 
table 460. These fields 468(2), 468(5) make user/object 
registration records explicitly correspond to particular VDE 
objects 300. 

Header 468 may also include a tag 468(7) that permits 
validation. In one example arrangement, the tag 468(7) 
within the user/object registration header 468 may be the 
same as the tag 466(8) within the object registration record 
460(N) that points to the user/object registration header. 
Correspondence between these tags 468(7) and 466(8) per- 
mits validation that the object registration record and user/ 
object registration header match up. 

User/object header 468 also includes an original distribu- 
tor ID field 468(3) indicating the original distributor of the 
corresponding VDE object 300, and the last distributor ID 
field 468(4) that indicates the last distributor within the 
chain of handling of the object prior to its receipt by 
electronic appliance 600. 

Header 468 also includes a tag 468(8) allowing validation 
between the header and the "first" subject record 470(1) 
which field 468(6) references. 

Subject record 470(1) includes a site record number 
472(1), a user (or user group) ID field 472(2), a user (or user 
group) attributes field 472(3), a field 472(4) referencing user 
rights table 464, a field 472(5) that references to the "next" 
subject record 470(2) (if there is one), a tag 472(6) used to 
validate with the header tag 468(8), a tag 472(7) used to 
validate with a corresponding tag in the user rights table 
record referenced by field 472(4), a tag 472(9) used to 
validate with a tag in the "next" subject record referenced to 
by field 472(5) and a check value field 472(9). 

User or user group ID 472(2) identifies a user or a user 
group authorized to use the object identified in field 468(5). 
Thus, the fields 468(5) and 472(2) together form the heart of 
the access control list provided by subject table 462. User 
attributes field 472(3) may specify attributes pertaining to 
use/access to object 300 by the user or user group specified 
in fields 472(2). Any number of different users or user 
groups may be added to the access control list (each with a 
different set of attributes 472(3)) by providing additional 
subject records 470 in the "linked list" structure. 

Subject record reference field 472(4) references one or 
more records within user rights table 464. FIG. 33 shows an 
example of a preferred format for a user rights table record 



>2,900 

166 

464(fc). User rights record 464(Jt) may include a URT header 
474, a record rights header 476, and a set of user choice 
records 478. URT header 474 may include a site record 
number field, a field 474(2) specifying the number of rights 

5 records within the URT record 464(Jt), a field 474(3) refer- 
encing a "first" rights record (i.e., to rights record header 
476), a tag 474(4) used to validate the lookup from the 
subject table 462, a tag 474(5) used to validate the lookup to 
the rights record header 476, and a check value field 474(6). 

10 Rights record header 476 in the preferred embodiment 
may include site record number field 476(1), a right ID field 
476(2), a field 476(3) referencing the "next" rights record 
476(2), a field 476(4) referencing a first set of user choice 
records 478(1), a tag 476(5) to allow validation with URT 

15 header tag 474(5), a tag 476(6) to allow validation with a 
user choice record tag 478(6), and a check value field 
476(7). Right ID field 476(2) may, for example, specify the 
type of right conveyed by the rights record 476 (e.g., right 
to use, right to distribute, right to read, right to audit, etc.). 

20 The one or more user choice records 478 referenced by 
rights record header 476 sets forth the user choices corre- 
sponding to access and/or use of the corresponding VDE 
object 300. There will typically be a rights record 476 for 
each right authorized to the corresponding user or user 

25 group. These rights govern use of the VDE object 300 by 
that user or user group. For instance, the user may have an 
"access" right, and an "extraction" right, but not a "copy" 
right. Other rights controlled by rights record 476 (which is 
derived from PERC 808 using a REGISTER method in the 

30 preferred embodiment) include distribution rights, audit 
rights, and pricing rights. When an object 300 is registered 
with the electronic appliance 600 and is registered with a 
particular user or user group, the user may be permitted to 
select among various usage methods set forth in PERC 808. 

35 For instance, a VDE object 300 might have two required 
meter methodologies: one for billing purposes, and one for 
accumulating data concerning the promotional materials 
used by the user. The user might be given the choice of a 
variety of meter/billing methods, such as: payment by VISA 

40 or MasterCard; choosing between billing based upon the 
quantity of material retrieved from an information database, 
based on the time of use, and/or both. Hie user might be 
offered a discount on time and/or quantity billing if he is 
willing to allow certain details concerning his retrieval of 

45 content to be provided to third parties (e.g., for demographic 
purposes). At the time of registration of an object and/or user 
for the object, the user would be asked to select a particular 
meter methodology as the "active metering method" for the 
first acquired meter. A VDE distributor might narrow the 

50 universe of available choices for the user to a subset of the 
original selection array stipulated by PERC 808. These user 
selection and configuration settings are stored within user 
choice records 480(1), 480(2), 480(N). The user choice 
records need not be explicitly set forth within user rights 

55 table 464; instead, it is possible for user choice records 480 
to refer (e.g., by site reference number) to particular VDE 
me mods and/or information parameterizing those methods. 
Such reference by user choice records 480 to method 1000 
should be validated by validation tags contained within the 

60 user choice records. Thus, user choice records 480 in the 
preferred embodiment may select one or more methods 1000 
for use with the corresponding VDE object 300 (as is shown 
in FIG. 27). These user choice records 480 may themselves 
fully define the methods 1000 and other information used to 

65 build appropriate components assemblies 690 for imple- 
menting the methods. Alternatively, the user/object record 
462 used to reference the user rights record 464 may also 
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reference the PERC 808 corresponding to VDE object 300 Updating Secure Database 610 

to provide additional information needed to build tie com- FIG. 35 show an example of a process 1150 which can be 

ponent assembly 690 and/or otherwise access the VDE used by a clearinghouse, VDE administrator or other VDE 

object 300. For example, PERC 808 may be accessed to participant to update the secure database 610 maintained by 

obtain MDEs 1202 pertaining to the selected methods, 5 *n end user's electronic appliance 600. For example, the 

private body and/or rights keys for decrypting and/or process 1500 shown in FIG. 35 might be used to collect 

encrypting object contents, and may also be used to provide " audit lraU " records ^ ihin database 610 and/or 

a checking capability ensuring that the user rights record P rovide new bud S ets Permissions (e.g., PERCs 808) in 

conveys only those rights authorized by a current authori- response to an end user s request. 

zation embodied within a PERC. 10 . £? lcaU * thc c ° d uscr .f . ck^ronic appliance 600 may 

j . ,. . .j i i .« j + mitiate communications with a clearinghouse (Block 1152). 

In one embodiment provided by the present invention, a . 4 e * . * Pi- u a # ♦• n 

i j A . . l j j This contact may, for example, be established automatically 

conventional database engjne may be used to store and 0f m ^ tQ a user comiMlsd _ It be ^ted across 

organize secure database 610, and the encryption layers me ele ctronic highway 108, or across other communications 
discussed above may be on top of the conventional networks such as a LAN, WAN, two-way cable or using 
database structure. However, if such a conventional database 15 portable media exchange between electronic appliances. The 
engine is unable to organize the records in secure database process of exchanging administrative information need not 
610 and support the security considerations outlined above, occur in a single "on line" session, but could instead occur 
then electronic appliance 600 may maintain separate index- over time based on a number of different one-way and/or 
ing structures in encrypted form. These separate indexing two-way communications over the same or different corn- 
structures can be maintained by SPE 503. This embodiment 20 munications means. However, the process 1150 shown in 
would require SPE 503 to decrypt the index and search FIG. 35 is a specific example where the end user's electronic 
decrypted index blocks to find appropriate "site record IDs" appliance 600 and the other VDE participant (e.g., a 
or other pointers. SPE 503 might then request the indicated clearinghouse) establish a two-way real-time interactive 
record from the conventional database engine. If the record communications exchange across a telephone line, network, 
ID cannot be checked against a record list, SPE 503 might 25 electronic highway 108, etc. 

be required to ask for the data file itself so it can retrieve the ^ end user's electronic appliance 600 generally con- 
desired record. SPE 503 would then perform appropriate tacts a P^cular VDE administrator or clearinghouse. The 
authentication to ensure that the file has not been tampered ldentlt y 5* * e Particular clearinghouse is based on the VDE 
with and that the proper block is returned. SPE 503 should ° b ' ect 300 * c user wishes to access or has already accessed, 
not simply pass the index to the conventional database 30 ^ ^ sup^ the user has already accessed a 
• / i .c j . u • • 1* \ * particular VDE object 300 and has run out of budget for 
engine (unless the da^ ^ access. The user could issue a request which will 
would allow an incorrect record to be swapped for the cause her electronic appliance 60 0 to automatically contact 
requested one. me VDE administrator, distributor and/or financial clearing- 

F1G. 34 is an example of how the site record numbers aouse th at Qas responsibility for that particular object. The 

described above may be used to access the various data 35 identity of the appropriate VDE participants to contact is 

structures within secure database 610. In this example, provided in the example by information within UDEs 1200, 

secure database 610 further includes a site record table 482 MDEs 1202, the Object Registration Table 460 and/or 

that stores a plurality of site record numbers. Site record Subject Table 462, for example. Electronic appliance 600 

table 482 may store what is in effect a "master list" of all may have to contact multiple VDE participants (e.g., to 

records within secure database 610. These site record num- 40 distribute audit records to one participant, obtain additional 

bers stored by site record table 482 permit any record within budgets or other permissions from another participant, etc.). 

secure database 610 to be accessed. Thus, some of the site The contact 1152 may in one example be scheduled in 

records within site record table 482 may index records with accordance with the FIG. 27 Shipping Table 444 and the 

an object registration table 460, other site record numbers FIG. 29 Administrative Event Log 442. 

within the site record table may index records within the 45 Once contact is established, the end user's electronic 

user/object table 462, still other site record numbers within appliance and the clearinghouse typically authenticate one 

the site record table may access records within URT464, and another and agree on a session key to use for thc real-time 

still other site record numbers within the site record table information exchange (Block 1154). Once a secure connec- 

may access PERCs 808. In addition, each of method cores tion is established, the end user's electronic appliance may 

1000 1 may also include a site record number so they may be 50 determine (e.g., based on Shipping Table 444) whether it has 

accessed by site record table 482. any administrative object(s) containing audit information 

FIG, 34A shows an example of a site record 482(/) within that it is supposed to send to the clearinghouse (decision 

site record table 482. Site record 482(/) may include a field Block 1156). Audit information pertaining to several VDE 

484(1) indicating the type of record, a field 484(2) indicating objects 300 may be placed within the same administrative 

the owner or creator of the record, a "class" field 484(3) and 55 object for transmission, or different administrative objects 

an "instance" field 484(4) providing additional information may contain audit information about different objects, 

about the record to which the site record 482(/) points; a Assuming the end user's electronic appliance has at least 

specific descriptor field 484(5) indicating some specific one such administrative object to send to this particular 

descriptor (e.g., object ID) associated with the record; an clearinghouse ("yes" exit to decision Block 1156), the 

identification 484(6) of the table or other data structure 60 electronic appliance sends that administrative object to the 

which the site record references; a reference and/or offset clearinghouse via the now-established secure real-time com- 

within that data structure indicating where the record begins; munications (Block 1158). In one specific example, a single 

a validation tag 484(8) for validating the record being administrative object may be sent an administrative object 

looked up, and a check value field 484(9). Fields 484(6) and containing audit information pertaining to multiple VDE 

484(7) together may provide the mechanism by which the 65 objects, with the audit information for each different object 

record referenced to by the site record 484(/) is actually compromising a separate "event" within the administrative 

physically located within the secure database 610. object. 
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The clearinghouse may receive the administrative object 
and process its contents to determine whether the contents 
are "valid" and "legitimate/' For example, the clearinghouse 
may analyze the contained audit information to determine 
whether it indicates misuse of the applicable VDE object 5 
300. The clearinghouse may, as a result of this analysis, may 
generate one or more responsive administrative objects that 
it then sends to the end user's electronic appliance 600 
(Block 1160). The end user's electronic appliance 600 may 
process events that update its secure database 610 and/or 10 
SPU 500 contents based on the administrative object 
received (Block 1162). For example, if the audit information 
received by the clearinghouse is legitimate, then the clear- 
inghouse may send an administrative object to the end user's 
electronic appliance 600 requesting the electronic appliance 15 
to delete and/or compress the audit information that has been 
transferred. Alternatively or in addition, the clearinghouse 
may request additional information from the end-user elec- 
tronic appliance 600 at this stage (e.g., retransmission of 
certain information that was corrupted during the initial 20 
transmission, transmission of additional information not 
earlier transmitted, etc.). If the clearinghouse detects misuse 
based on the received audit information, it may transmit an 
administrative object that revokes or otherwise modifies the 
end user's right to further access the associated VDE objects 25 
300. 

The clearinghouse may, in addition or alternatively, send 
an administrative object to the end user's electronic appli- 
ance 600 that instructs the electronic appliance to display 
one or more messages to the user. These messages may 30 
inform the user about certain conditions and/or they may 
request additional information from the user. For example, 
the message may instruct the end user to contact the clear- 
inghouse directly by telephone or otherwise to resolve an 
indicated problem, enter a PIN, or it may instruct the user to 35 
contact a new service company to re-register the associated 
VDE object Alternatively, the message may tell the end user 
that she needs to acquire new usage permissions for the 
object, and may inform the user of cost, status and other 
associated information. 40 

During the same or different communications exchange, 
the same or different clearinghouse may handle the end 
user's request for additional budget and/or permission per- 
taining to VDE object 300. For example, the end user's 
electronic appliance 600 may (e.g., in response to a user 45 
input request to access a particular VDE object 300) send an 
administrative object to the clearinghouse requesting bud- 
gets and/or other permissions allowing access (Block 1164). 
As mentioned above, such requests may be transmitted in 
the form of one or more administrative objects, such as, for 50 
example, a single administrative object having multiple 
"events" associated with multiple requested budgets and/or 
other permissions for the same or different VDE objects 300. 
The clearinghouse may upon receipt of such a request, check 
the end user's credit, financial records, business agreements 55 
and/or audit histories to determine whether the requested 
budgets and/or permissions should be given. The clearing- 
house may, based on this analysis, send one or more respon- 
sive administrative objects which cause the end user's 
electronic appliance 600 to update its secure database in 60 
response (Block 1166, 1168). This updating might, for 
example, comprise replacing an expired PERC 808 with a 
fresh one, modifying a PERC to provide additional (or 
lesser) rights, etc. Steps 1164-1168 may be repeated mul- 
tiple times in the same or different communications session 65 
to provide further updates to the end user's secure database 
610. 
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FIG. 36 shows an example of how a new record or 
element may be inserted into secure database 610. The load 
process 1070 shown in FIG. 35 checks each data element or 
item as it is loaded to ensure that it has not been tampered 
with, replaced or substituted. In the process 1070 shown in 
FIG. 35, the first step that is performed is to check to see if 
the current user of electronic appliance 600 is authorized to 
insert the item into secure database 610 (block 1072). This 
test may involve, in the preferred embodiment, loading (or 
using already loaded) appropriate methods 1000 and other 
data structures such as UDEs 1200 into an SPE 503, which 
then authenticates user authorization to make the change to 
secure database 610 (block 1074). If the user is approved as 
being authorized to make the change to secure database 610, 
then SPE 503 may check the integrity of the element to be 
added to the secure database by decrypting it (block 1076) 
and determining whether it has become damaged or cor- 
rupted (block 1078). The element is checked to ensure that 
it decrypts properly using a predetermined management file 
key, and the check value may be validated. In addition, the 
public and private header ID tags (if present) may be 
compared to ensure that the proper element has been pro- 
vided and had not been substituted, and the unique element 
tag ID compared against the predetermined element tag. If 
any of these tests fail, the element may be automatically 
rejected, error corrected, etc. Assuming the element is found 
to have integrity, SPE 503 may re-encrypt the information 
(block 1080) using a new key for example (see FIG. 37 
discussion below). In the same process step an appropriate 
tag is preferably provided so that the information becomes 
encrypted within a security wrapper having appropriate tags 
contained therein (block 1082). SPE 503 may retain appro- 
priate tag information so that it can later validate or other- 
wise authenticate the item when it is again read from secure 
database 610 (block 1084). The now-secure element within 
its security wrapper may then be stored within secure 
database 610. 

FIG, 37 shows an example of a process 1050 used in the 
preferred embodiment database to securely access an item 
stored in secure database 610. In the preferred embodiment, 
SPE 503 first accesses and reads in the item from secure 
database 610 records. SPE 503 reads this information from 
secure database 610 in encrypted form, and may "unwrap" 
it (block 1052) by decrypting it (block 1053) based on access 
keys internally stored within the protected memory of an 
SPU 500. In the preferred embodiment, this "unwrap" 
process 1052 involves sending blocks of information to 
encrypt/decrypt engine 522 along with a management file 
key and other necessary information needed to decrypt. 
Decrypt engine 522 may return "plaintext" information that 
SPE 503 then checks to ensure that the security of the object 
has not been breached and that the object is the proper object 
to be used (block 1054). SPE 503 may then check all 
correlation and access tags to ensure that the read-in element 
has not been substituted and to guard against other security 
threats (block 1054). Part of this "checking" process 
involves checking the tags obtained from the secure data- 
base 610 with tags contained within the secure memory or 
an SPU 500 (block 1056). These tags stored within SPU 500 
may be accessed from SPU protected memory (block 1056) 
and used to check further the now-unwrapped object. 
Assuming this "checking" process 1054 does not reveal any 
improprieties (and block 1052 also indicates that the object 
has not become corrupted or otherwise damaged), SPE 503 
may then access or otherwise use the item (block 1058). 
Once use of the item is completed, SPE 503 may need to 
store the item back into secure database 610 if it has 
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changed. If the item has changed, SPE 503 will send the item other records with secure database 610 with the same new 
in its changed form to encrypt/decrypt engine 522 for key in order to reduce the number of (or change) encryption/ 
encryption (block 1060), providing the appropriate neces- decryption keys in use. Thus, one or more secure database 
sary information to the encrypt/decrypt engine (e.g., the 610 items may be read from the secure database (block 
appropriate same or different management file key and data) S 1092), and decrypted using the old key(s) used to encrypt 
so that the object is appropriately encrypted. A unique, new them the last time they were stored. In the preferred 
tag and/or encryption key may be used at this stage to embodiment, one or more "old keys" are selected, and all 
uniquely tag and/or encrypt the item security wrapper (block secure database items encrypted using the old key(s) are 
1062; see also detailed FIG. 37 discussion below). SPE 503 read and decrypted. These records may now be re-encrypted 
may retain a copy of the key and/or tag within a protected 10 using the new key that was generated at block 1086 for the 
memory of SPU 500 (block 1064) so that the SPE can new record (block 1094). The old key(s) used to decrypt the 
decrypt and validate the object when it is again read from other record(s) may now be removed from the SPU pro- 
secure database 610. tected memory (block 1096), and the new key stored in its 
The keys to decrypt secure database 610 records are, in place (block 1097). The old key(s) cannot be removed from 
the preferred embodiment, maintained solely within the 15 secure memory by block 1096 unless SPE 503 is assured that 
protected memory of an SPU 500. Each index or record all records within the secure database 610 that were 
update that leaves the SPU 500 may be time stamped, and encrypted using the old key(s) have been read by block 1092 
then encrypted with a unique key that is determined by the and re-encrypted by block 1904 using the new key. All 
SPE 503. For example, a key identification number may be records encrypted (or re-encrypted) using the new key may 
placed "in plain view" at the front of the records of secure 20 now be stored in secure database 610 (block 1098). If 
database 610 so the SPE 503 can determine which key to use decision block 1090 determines there is room within the 
the next time the record is retrieved. SPE 503 can maintain SPU 500 protected memory to store the new key, then the 
the site ID of the record or index, the key identification operations of blocks 1092, 1094, 1096 are not needed and 
number associated with it, and the actual keys in the list SPE 503 may instead simply store the new key within the 
internal to the SPE. At some point, this internal list may fiD 25 protected memory (block 1097) and store the new encrypted 
up. At this point, SPE 503 may call a maintenance routine records into secure database 610 (block 1098). 
that re-encrypts items within secure database 610 containing The security of secure database 610 files may be further 
changed information. Some or all of the items within the improved by segmenting the records into "compartments." 
data structure containing changed information may be read Different encryption/decryption keys may be used to protect 
in, decrypted, and then re-encrypted with the same key. 30 different "compartments." This strategy can be used to limit 
These items may then be issued the same key identification the amount of information within secure database 610 that is 
number. The items may then be written out of SPE 503 back encrypted with a single key. Another technique for increas- 
ing secure database 610. SPE 503 may then clear the ing security of secure database 610 may be to encrypt 
internal list of item IDs and corresponding key identification different portions of the same records with different keys so 
numbers. It may then begin again the process of assigning a 35 that more than one key may be needed to decrypt those 
different key and a new key identification number to each records, 
new or changed item. By using this process, SPE 503 can 

protect the data structures (including the indexes) of secure Backup of Secure Database 610 

database 610 against substitution of old items and against CaflM „ . « . _ £1A ... f . ... 

u * * *• c a c * t,. & . Secure database 610 in the preferred embodiment is 

substitution of indexes for current items. This process also 40 . , , , ... , / . . . «_ 

ii one em * i m * * • a u m . , (L backed up at periodic or other time intervals to protect the 

allows SPE 503 to validate retrieved item IDs against the . f # - * , . . ■ ^™ ■ j . 

encrypted list of expected IDs information the secure database contains. This secure data- 

r?n id- a u * u •" *l* a . t base information may be of substantial value to many VDE 

FIG. 38 is a flowchart showing this process in more detail. . . D i c j « u l ■/ 

M , a * u £in a * a participants. Back ups of secure database 610 should occur 

Whenever a secure database 610 item is updated or . ... • • t tU j L u 

j *o . , , , j /• « without significant inconvenience to the user, and should not 

modified, a new encryption key can be generated for the 45 . , & ' 

a * a * c • i • a breach any security, 

updated item. Encryption using a new key is performed to J J 

add security and to prevent misuse of backup copies of ^ need t0 back U P secure database 610 maybe checked 

secure database 610 records. The new encryption key for at P ower on of electronic appliance 600, when SPE 503 is 

each updated secure database 610 record may be stored in 1Dltiall y invoked, at periodic time intervals, and if "audit roll 

SPU 500 secure memory with an indication of the secure 50 V value or other summary services information maintained 

database record or record(s) to which it applies. bv SPE 503 exceeds a **** ^ or other threshold, or 

SPE 503 may generate a new encryption/decryption key triggered by catena established by one or more content 

for each new item it is going to store within secure database Pushers and/or distributors and/or clearinghouse service 

610 (block 1086). SPE 503 may use this new key to encrypt providers and/or users. The user may be prompted to backup 

the record prior to storing it in the secure database (block 55 tf ^ has failed t0 do 50 b V or al some certain P omt in dme 

1088). SPE 503 make sure that it retains the key so that it can or rf tcr a ccrtaia 4"*^°* time or quantity of usage, or the 

later read and decrypt the record. Such decryption keys are, backu P ma y P^cecd automatically without user interven- 

in the preferred embodiment, maintained within protected Uorj ' 

non- volatile memory (e.g., NVRAM 534b) within SPU 500. Referring to FIG. 8, backup storage 668 and storage 

Since this protected memory has a limited size, there may 60 media 670 (e.g., magnetic tape) may be used to store backed 

not be enough room within the protected memory to store a up information. Of course, any non-volatile media (e.g., one 

new key. This condition is tested for by decision block 1090 or more floppy diskettes, a writable optical diskette, a hard 

in the preferred embodiment. If there is not enough room in drive, or the like) may be used for backup storage 668. 
memory for the new key (or some other event such as the There are at least two scenarios to backing up secure 

number of keys stored in the memory exceeding a prede- 65 database 610. The first scenario is "site specific," and uses 

termined number, a timer has expired, etc.), then the pre- the security of SPU 500 to support restoration of the backed 

ferred embodiment handles the situation by re-encrypting up information. This first method is used in case of damage 
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to secure database 610 due for example to failure of sec- 
ondary storage device 652, inadvertent user damage to the 
files, or other occurrences that may damage or corrupt some 
or all of secure database 610. This first, site specific scenario 
of back up assumes that an SPU 500 still functions properly 
and is available to restore backed up information. 

The second back up scenario assumes that the user's SPU 
500 is no longer operational and needs to be, or has been, 
replaced. This second approach permits an authorized VDE 
administrator or other authorized VDE participant to access 
the stored back up information in order to prevent loss of 
critical data and/or assist the user in recovering from the 
error. 

Both of these scenarios are provided by the example of 
program control steps performed by ROS 602 shown in FIG. 
39. FIG. 39 shows an example back up routine 1250 
performed by an electronic appliance 600 to back up secure 
database 610 (and other information) onto back up storage 
668. Once a back up has been initiated, as discussed above, 
back up routine 1250 generates one or more back up keys 
(block 1252). Back up routine 1250 then reads all secure 
database items, decrypts each item using the original key 
used to encrypt them before they were stored in secure 
database 610 (block 1254). Since SPU 500 is typically the 
only place where the keys for decrypting this information 
within an instance of secure database 610 are stored, and 
since one of the scenarios provided by back up routine 1250 
is that SPU 500 completely failed or is destroyed, back up 
routine 1250 performs this reading and decrypting step 1254 
so that recovery from a backup is not dependent on knowl- 
edge of these keys within the SPU. Instead, back up routine 
1250 encrypts each secure database 610 item with a newly 
generated back up key(s) (block 1256) and writes the 
encrypted item to back up store 668 (block 1258). This 
process continues until all items within secure database 610 
have been read, decrypted, encrypted with a newly gener- 
ated back up key(s), and written to the back up store (as 
tested for by decision block 1260). 

The preferred embodiment also reads the summary ser- 
vices audit information stored within the protected memory 
of SPU 500 by SPE summary services manager 560, 
encrypts this information with the newly generated back up 
key(s), and writes this summary services information to 
back up store 668 (block 1262). 

Finally, back up routine 1250 saves the back up key(s) 
generated by block 1252 and used to encrypt in blocks 1256, 
1262 onto back up store 668. It does this in two secure ways 
in order to cover both of the restoration scenarios discussed 
above. Back up routine 1250 may encrypt the back up key(s) 
(along with other information such as the time of back up 
and other appropriate information to identify the back up) 
with a further key or keys such that only SPU 500 can 
decrypt (block 1264). This encrypted information is then 
written to back up store 668 (block 1264). For example, this 
step may include multiple encryptions using one or more 
public keys with corresponding private keys known only to 
SPU 500. Alternatively, a second back up key generated by 
the SPU 500 and kept only in the SPU may be used for the 
final encryption in place of a public key. Block 1264 
preferably includes multiple encryption in order to make it 
more difficult to attack the security of the back up by 
"cracking" the encryption used to protect the back up keys. 
Although block 1262 includes encrypted summary services 
information on the back up, it preferably does not include 
SPU device private keys, shared keys, SPU code and other 
internal security information to prevent this information 
from ever becoming available to users even in encrypted 
form. 
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The information stored by block 1264 is sufficient to 
allow the same SPU 500 that performed (or at least in part 
performed) back up routine 1250 to recover the backed up 
information. However, this information is useless to any 

5 device other than that same SPU because only that SPU 
knows the particular keys used to protect the back up keys. 
To cover the other possible scenario wherein the SPU 500 
fails in a non-recoverable way, back up routine 1250 pro- 
vides an additional step (block 1266) of saving the back up 

1Q key(s) under protection of one or more further set of keys 
that may be read by an authorized VDE administrator. For 
example, block 1266 may encrypt the back up keys with an 
"download authorization key" received during initialization 
of SPU 500 from a VDE administrator. This encrypted 

15 version of back up keys is also written to back up store 668 
(block 1266). It can be used to support restoration of the 
back up files in the event of an SPU 500 failure. More 
specifically, a VDE administrator that knows the download 
authorization (or other) keys(s) used by block 1266 may be 

2Q able to recover the back up key(s) in the back up store 668 
and proceed to restore the backed up secure database 610 to 
the same or different electronic appliance 600. 

In the preferred embodiment, the information saved by 
routine 1250 in back up files can be restored only after 

^ receiving a back up authorization from an authorized VDE 
administrator. In most cases, the restoration process will 
simply be a restoration of secure database 610 with some 
adjustments to account for any usage since the back up 
occurred. This may require the user to contact additional 

30 providers to transmit audit and billing data and receive new 
budgets to reflect activity since the last back up. Current 
summary services information maintained within SPU 500 
may be compared to the summary services information 
stored on the back up to determine or estimate most recent 

35 usage activity. 

In case of an SPU 500 failure, an authorized VDE 
administrator must be contacted to both initialize the 
replacement SPU 500 and to decrypt the backup files. These 
processes allow for both SPU failures and upgrades to new 

40 SPUs. In the case of restoration, the back up files are used 
to restore the necessary information to the user's system. In 
the case of upgrades, the back up files may be used to 
validate the upgrade process. 
The back up files may in some instances be used to 

45 transfer management information between electronic appli- 
ances 600. However, the preferred embodiment may restrict 
some or all information from being transportable between 
electronic appliances with appropriate authorizations. Some 
or all of the back up files may be packaged within an 

50 administrative object and transmitted for analysis, 
transportation, or other uses. 

As a more detailed example of a need for restoration from 
back up files, suppose an electronic appliance 600 suffers a 
hard disk failure or other accident that wipes out or corrupts 

55 part or all of the secure database 610, but assume that the 
SPU 500 is still functional. SPU 500 may include all of the 
information (e.g., secret keys and the like) it needs to restore 
the secure database 610. However, ROS 602 may prevent 
secure database restoration until a restoration authorization 

60 is received from a VDE administrator. A restoration autho- 
rization may comprise, for example, a "secret value" that 
must match a value expected by SPE 503. A VDE admin- 
istrator may, if desired, only provide this restoration autho- 
rization after, for example, summary services information 

65 stored within SPU 500 is transmitted to the administrator in 
an administrative object for analysis. In some circumstances, 
a VDE administrator may require that a copy (partial or 
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complete) of the back up files be transmitted to it within an obtaining, from other VDE participants, reports and other 

administrative object to check for indications of fraudulent information pertaining to usage by the electronic appliance 

activities by the user. The restoration process, once prior to its failure and comparing it to the secure database 

authorized, may require adjustment of restored budget backup to determine which usage and other events are not 

records and the like to reflect activity since the last back up, 5 yet accounted for. 

as mentioned above. In one alternate embodiment, SPU 500 may have suffi- 

FIG. 40 is an example of program controlled "restore" cient internal, non-volatile memory to allow it to store some 

routine 1268 performed by electronic appliance 600 to or all of secure database 610. In this embodiment, the 

restore secure database 610 based on the back up provided additional memory may be provided by additional one or 

by the routine shown in FIG. 38. This restore may be used, 10 more integrated circuits that can be contained within a 

for example, in the event that an electronic appliance 600 secure enclosure, such as a tamper resistant metal container 

has failed but can be recovered or "reinitialized" through or some form of a chip pack containing multiple integrated 

contact with a VDE administrator for example. Since the circuit components, and which impedes and/or evidences 

preferred embodiment does not permit an SPU 500 to restore tampering attempts, and/or disables a portion or all of SPU 

from backup unless and until authorized by a VDE 15 500 or associated critical key and/or other control informa- 

administrator, restore routine 1268 begins by establishing a tion in the event of tampering. The same back up routine 

secure communication with a VDE administrator that can 1250 shown in FIG. 38 may be used to back up this type of 

authorize the restore to occur (block 1270). Once SPU 500 information, the only difference being that block 1254 may 

and the VDE administrator authenticate one another (part of read the secure database item from the SPU internal memory 

block 1270), the VDE administrator may extract "work in 20 and may not need to decrypt it before encrypting it with the 

progress" and summary values from the SPU 500*s internal back up key(s). 

non-volatile memory (block 1272). The VDE administrator p n . vnrc 

may use this extracted information to help determine, for Hvent-Unven VUfc Processes 

example, whether there has been a security violation, and As discussed above, processes provided by/under the 

also permits a failed SPU 500 to effectively "dump" its M preferred embodiment rights operating system (ROS) 602 

contents to the VDE administrator to permit the VDE ma y be " event driven." This "event driven" capability 

administrator to handle the contents. The SPU 500 may facilitates integration and extendibility. 

encrypt this information and provide it to the VDE admin- An "event" is a happening at a point in time. Some 

istrator packaged in one or more administrative objects. The examples of "events" are a user striking a key of a keyboard, 

VDE administrator may then request a copy of some or all 30 arrival of a message or an object 300, expiration of a timer, 

of the current backup of secure database 610 from the SPU or a request from another process. 

500 (block 1274). This information may be packaged by In the preferred embodiment, ROS 602 responds to an 

SPU 500 into one or more administrative objects, for "event" by performing a process in response to the event, 

example, and sent to the VDE administrator. Upon receiving ROS 602 dynamically creates active processes and tasks in 

the information, the VDE administrator may read the sum- 35 response to the occurrence of an event. For example, ROS 

mary services audit information from the backup volume 602 may create and begin executing one or more component 

(i.e., information stored by FIG. 38 block 1262) to determine assemblies 690 for performing a process or processes in 

the summary values and other information stored at time of response to occurrence of an event. The active processes and 

backup. The VDE administrator may also determine the time tasks may terminate once ROS 602 has responded to the 

and date the backup was made by reading the information 4Q event. This ability to dynamically create (and end) tasks in 

stored by FIG. 38 block 1264. response to events provides great flexibility, and also permits 

The VDE administrator may at this point restore the limited execution resources such as those provided by an 

summary values and other information within SPU 500 SPU 500 to perform a virtually unlimited variety of different 

based on the information obtained by block 1272 and from processes in different contexts, 

the backup (block 1276). For example, the VDE adminis- 45 Since an "event" may be any type of happening, there are 

trator may reset SPU internal summary values and counters an unlimited number of different events. Thus, any attempt 

so that they are consistent with the last backup. These values to categorize events into different types will necessarily be 

may be adjusted by the VDE administrator based on the a generalization. Keeping this in mind, it is possible to 

"work in progress" recovered by block 1272, the amount of categorize events provided/supported by the preferred 

time that has passed since the backup, etc. The goal may 50 embodiment into two broad categories: 

typically be to attempt to provide internal SPU values that user-initiated events; and 

are equal to what they would have been had the failure not system-initiated events. 

occurred. Generally, "user-initiated" events are happenings attrib- 
The VDE administrator may then authorize SPU 500 to utable to a user (or a user application). A common "user- 
recover its secure database 610 from the backup files (block ss initiated" event is a user's request (e.g., by pushing a 
1278). This restoration process replaces all secure database keyboard button, or transparently using redirector 684) to 
610 records with the records from the backup. The VDE access an object 300 or other VDE-protected information, 
administrator may adjust these records as needed by passing "System-initiated" events are generally happenings not 
commands to SPU 500 during or after the restoration attributable to a user. Examples of system initiated events 
process. 60 include the expiration of a timer indicating that information 
The VDE administrator may then compute bills based on should be backed to non-volatile memory, receipt of a 
the recovered values (block 1280), and perform other actions message from another electronic appliance 600, and a ser- 
to recover from SPU downtime (block 1282). Typically, the vice call generated by another process (which may have 
goal is to bill the user and adjust other VDE 100 values been started to respond to a system-initiated event and/or a 
pertaining to the failed electronic appliance 600 for usage 65 user-initiated event). 

that occurred subsequent to the last backup but prior to the ROS 602 provided by the preferred embodiment responds 

failure. This process may involve the VDE administrator to an event by specifying and beginning processes to process 
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the event. These processes are, in the preferred embodiment, 
based on methods 1000. Since there are an unlimited number 
of different types of events, the preferred embodiment 
supports an unlimited number of different processes to 
process events. This flexibility is supported by the dynamic 5 
creation of component assemblies 690 from independently 
deliverable modules such as method cores 1000', load mod- 
ules 1100, and data structures such as UDEs 1200. Even 
though any categorization of the unlimited potential types of 
processes supported/provided by the preferred embodiment no 
will be a generalization, it is possible to generally classify 
processes as falling within two categories: 

processes relating to use of VDE protected information; 
and 

processes relating to VDE administration. 15 
"Use" and "Administrative" Processes 

"Use" processes relate in some way to use of VDE- 
protected information. Methods 1000 provided by the pre- 2Q 
ferred embodiment may provide processes for creating and 
maintaining a chain of control for use of VDE-protected 
information. One specific example of a "use" type process is 
processing to permit a user to open a VDE object 300 and 
access its contents. A method 1000 may provide detailed ^ 
use-related processes such as, for example, releasing content 
to the user as requested (if permitted), and updating meters, 
budgets, audit trails, etc. Use-related processes are often 
user-initiated, but some use processes may be system- 
initiated. Events that trigger a VDE use-related process may 30 
be called "use events." 

An "administrative" process helps to keep VDE 100 
working. It provides processing that helps support the trans- 
action management "infrastructure" that keeps VDE 100 
running securely and efficiently. Administrative processes 35 
may, for example, provide processing relating to some 
aspect of creating, modifying and/or destroying VDE- 
protected data structures that establish and maintain VDE's 
chain of handling and control. For example, "administra- 
tive" processes may store, update, modify or destroy infor- 40 
mation contained within a VDE electronic appliance 600 
secure database 610. Administrative processes also may 
provide communications services that establish, maintain 
and support secure communications between different VDE 
electronic appliances 600. Events that trigger administrative 45 
processes may be called "administrative events." 

Reciprocal Methods 

Some VDE processes are paired based on the way they 
interact together. One VDE process may "request" process- 50 
ing services from another VDE process. The process that 
requests processing services may be called a "request pro- 
cess." The "request" constitutes an "event" because it trig- 
gers processing by the other VDE process in the pair. The 
VDE process that responds to the "request event" may be 55 
called a "response process." The "request process" and 
"response process" may be called "reciprocal processes." 

The "request event" may comprise, for example, a mes- 
sage issued by one VDE node electronic appliance 600 or 
process for certain information. A corresponding "response 60 
process" may respond to the "request event" by, for 
example, sending the information requested in the message. 
This response may itself constitute a "request event" if it 
triggers a further VDE "response process." For example, 
receipt of a message in response to an earlier-generated 65 
request may trigger a "reply process." This "reply process" 
is a special type of "response process" that is triggered in 
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response to a "reply** from another "response process." 
There may be any number of "request" and "response" 
process pairs within a given VDE transaction. 

A "request process" and its paired "response process" 
may be performed on the same VDE electronic appliance 
600, or the two processes may be performed on different 
VDE electronic appliances. Communication between the 
two processes in the pair may be by way of a secure 
(VDE-protected) communication, an "out of channel" 
communication, or a combination of the two. 

FIGS. 41a-41d are a set of examples that show how the 
chain of handling and control is enabled using "reciprocal 
methods." A chain of handling and control is constructed, in 
part, using one or more pairs of "reciprocal events" that 
cooperate in request-response manner. Pairs of reciprocal 
events may be managed in the preferred embodiment in one 
or more "reciprocal methods." As mentioned above, a 
"reciprocal method" is a method 1000 that can respond to 
one or more "reciprocal events." Reciprocal methods con- 
tain the two halves of a cooperative process that may be 
securely executed at physically and/or temporally distant 
VDE nodes. The reciprocal processes may have a flexibly 
defined information passing protocols and information con- 
tent structure. The reciprocal methods may, in fact, be based 
on the same or different method core 1000' operating in the 
same or different VDE nodes 600. VDE nodes 600A and 
600B shown in FIG. 41a may be the same physical elec- 
tronic appliance 600 or may be separate electronic appli- 
ances. 

FIG. 41a is an example of the operation of a single pair 
of reciprocal events. In VDE node 600A, method 1000a is 
processing an event that has a request that needs to be 
processed at VDE node 600B. The method 1000a (e.g., 
based on a component assembly 690 including its associated 
load modules 1100 and data) that responds to this "request" 
event is shown in FIG. 41a as 1450, The process 1450 
creates a request (1452) and, optionally, some information or 
data that will be sent to the other VDE node 1000b for 
processing by a process associated with the reciprocal event. 
The request and other information may be transmitted by 
any of the transport mechanisms described elsewhere in this 
disclosure. 

Receipt of the request by VDE node 6006 comprises a 
response event at that node. Upon receipt of the request, the 
VDE node 6006 may perform a "reciprocal" process 1454 
defined by the same or different method 10006 to respond to 
the response event. The reciprocal process 1454 may be 
based on a component assembly 690 (e.g., one or more load 
modules 1100, data, and optionally other methods present in 
the VDE node 600B). 

FIG. 416 extends the concepts presented in FIG. 41a to 
include a response from VDE node 600B back to VDE node 
600A. The process starts as described for FIG. 41a through 
the receipt and processing of the request event and infor- 
mation 1452 by the response process 1454 in VDE node 
600B. The response process 1454 may, as part of its 
processing, cooperate with another request process (1468) to 
send a response 1469 back to the initiating VDE node 600 A 
A corresponding reciprocal process 1470 provided by 
method 1000A may respond to and process this request 
event 1469. In this manner, two or more VDE nodes 600A, 
600B may cooperate and pass configurable information and 
requests between methods 1000A, 1000B executing in the 
nodes. The first and second request-response sequences 
[(1450, 1452, 1454) and (1468, 1469, 1470)] may be sepa- 
rated by temporal and spatial distances. For efficiency, the 
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request (1468) and response (1454) processes may be based 
on tbe same method 1000 or they may be implemented as 
two methods in the same or different method core 1000'. A 
method 1000 may be parameterized by an "event code" so 
it may provide different behaviors/results for different 5 
events, or different methods may be provided for different 
events. 

FIG. 41c shows the extension the control mechanism 
described in FIGS. 41a-41b to three nodes (600A, 600B, 
600Q. Each request-response pair operates in the manner as 10 
described for FIG. 41b, with several pairs linked together to 
form a chain of control and handling between several VDE 
nodes 600 A, 600B, 600C. This mechanism may be used to 
extend the chain of handling and control to an arbitrary 
number of VDE nodes using any configuration of nodes. For 15 
example, VDE node 600C might communicate directly to 
VDE node 600A and communicate directly to VDE 600B, 
which in turn communicates with VDE node 600A. 
Alternately, VDE node 600C might communicate directly 
with VDE node 600A, VDE node 600A may communicate 20 
with VDE node 600B, and VDE node 600B may commu- 
nicate with VDE node 600C 

A method 1000 may be parameterized with sets of events 
that specify related or cooperative functions. Events may be 
logically grouped by function (e.g., use, distribute), or a set 25 
of reciprocal events that specify processes that may operate 
in conjunction with each other. FIG. 41d illustrates a set of 
"reciprocal events" that support cooperative processing 
between several VDE nodes 102, 106, 112 in a content 
distribution model to support the distribution of budget. The 30 
chain of handling and control, in this example, is enabled by 
using a set of "reciprocal events" specified within a BUD- 
GET method. FIG. 41d is an example of how the reciprocal 
event behavior within an example BUDGET method (1510) 
work in cooperation to establish a chain of handling and 35 
control between several VDE nodes. The example BUDGET 
method 1510 responds to a "use" event 1478 by performing 
a "use" process 1476 that defines the mechanism by which 
processes are budgeted. The BUDGET method 1510 might, 
for example, specify a use process 1476 that compares a 40 
meter count to a budget value and fail the operation if the 
meter count exceeds the budget value. It might also write an 
audit trail that describes the results of said BUDGET deci- 
sions. Budget method 1510 may respond to a "distribute" 
event by performing a distribute process 1472 that defines 45 
the process and/or control information for further distribu- 
tion of the budget. It may respond to a "request" event 1480 
by performing a request process 1480 that specifies how the 
user might request use and/or distribution rights from a 
distributor. It may respond to a "response" event 1482 by 50 
performing a response process 1484 that specifies the man- 
ner in which a distributor would respond to requests from 
other users to whom they have distributed some (or all) of 
their budget to. It may respond to a "reply" event 1474 by 
performing a reply process 1475 that might specify how the 55 
user should respond to message regranting or denying 
(more) budget. 

Control of event processing, reciprocal events, and their 
associated methods and method components is provided by 
PERCs 808 in the preferred embodiment. These PERCs 60 
(808) might reference administrative methods that govern 
the creation, modification, and distribution of the data struc- 
tures and administrative methods that permit access, 
modification, and further distribution of these items. In this 
way, each link in the chain of handling and control might, for 65 
example, be able to customize audit information, alter the 
budget requirements for using the content, and/or control 
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further distribution of these rights in a manner specified by 
prior members along the distribution chain. 

In the example shown in FIG. 41d, a distributor at a VDE 
distributor node (106) might request budget from a content 
creator at another node (102). This request may be made in 
the context of a secure VDE communication or it may be 
passed in an "out-of-channel" communication (e.g. a tele- 
phone call or letter). The creator 102 may decide to grant 
budget to the distributor 106 and processes a distribute event 
(1452 in BUDGET method 1510 at VDE node 102). A result 
of processing the distribute event within the BUDGET 
method might be a secure communication (1454) between 
VDE nodes 102 and 106 by which a budget granting use and 
redistribute rights to the distributor 106 may be transferred 
from the creator 102 to the distributor. The distributor's 
VDE node 106 may respond to the receipt of the budget 
information by processing the communication using the 
reply process 1475B of the BUDGET method 1510. The 
reply event processing 1475B might, for example, install a 
budget and PERC 808 within the distributor's VDE 106 
node to permit the distributor to access content or processes 
for which access is control at least in part by the budget 
and/or PERC. At some point, the distributor 106 may also 
desire to use the content to which she has been granted rights 
to access. 

After registering to use the content object, the user 112 
would be required to utilize an array of "use" processes 
1476 C to, for example, open, read, write, and/or close the 
content object as part of the use process. 

Once the distributor 106 has used some or all of her 
budget, she may desire to obtain additional budget. The 
distributor 106 might then initiate a process using the 
BUDGET method request process (1480B). Request process 
1480B might initiate a communication (1482AB) with the 
content creator VDE node 102 requesting more budget and 
perhaps providing details of the use activity to date (e.g., 
audit trails). The content creator 102 processes the 'get more 
budget' request event 1482AB using the response process 
(1484A) within the creator's BUDGET method 1510A. 
Response process 1484A might, for example, make a deter- 
mination if the use information indicates proper use of the 
content, and/or if the distributor is credit worthy for more 
budget. The BUDGET method response process 1484A 
might also initiate a financial transaction to transfer funds 
from the distributor to pay for said use, or use the distribute 
process 1472A to distribute budget to the distributor 106. A 
response to the distributor 106 granting more budget (or 
denying more budget) might be sent immediately as a 
response to the request communication 1482AB, or it might 
be sent at a later time as part of a separate communication. 
The response communication, upon being received at the 
distributor's VDE node 106, might be processed using the 
reply process 1475B within the distributor's copy of the 
BUDGET method 1510B. The reply process 1475B might 
then process the additional budget in the same manner as 
described above. 

The chain of handling and control may, in addition to 
posting budget information, also pass control information 
that governs the manner in which said budget may be 
utilized. For example, the control information specified in 
the above example may also contain control information 
describing the process and limits that apply to the distribu- 
tor's redistribution of the right to use the creator's content 
object. Thus, when the distributor responds to a budget 
request from a user (a communication between a user at 
VDE node 112 to the distributor at VDE node 106 similar in 
nature to the one described above between VDE nodes 106 
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and 102) using the distribute process 1472B within the 
distributor's copy of the BUDGET method 1510B, a distri- 
bution and request/response/reply process similar to the one 
described above might be initiated. 

Thus, in this example a single method can provide mul- 
tiple dynamic behaviors based on different "triggering" 
events. For example, single BUDGET method 1510 might 
support any or all of the events listed below: 
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-continued 



Event TVpc 



Event 



Process Description 



Processed by 
Distributor Node 
Request Process 
1484B 



Provide More to user 

Provide Update to user. 

Audit user 

Delete user's method 



Provide more budget to 
user. 

Provided updated budget 
to user. 

Audit a specified user. 
Delete method belonging 
to user. 



10 



Event Type Event Process Description 



Examples of Reciprocal Method Processes 
A. BUDGET 

FIGS. 4,2a, 42b, 42c and 42d, respectively, are flowcharts 

15 of example process control steps performed by a represen- 
tative example of BUDGET method 2250 provided by the 
preferred embodiment. In the preferred embodiment, BUD- 
GET method 2250 may operate in any of four different 
modes: 

20 use (see FIG. 42a) 

administrative request (see FIG. 42b) 
administrative response (see FIG. 42c) 
administrative reply (see FIG. 42d). 
In general, the "use" mode of BUDGET method 2250 is 

25 invoked in response to an event relating to the use of an 
object or its content. The "administrative request" mode of 
BUDGET method 2250 is invoked by or on behalf of the 
user in response to some user action that requires contact 
with a VDE financial provider, and basically its task is to 

30 send an administrative request to the VDE financial pro- 
vider. The "administrative response" mode of BUDGET 
method 2250 is performed at the VDE financial provider in 
response to receipt of an administrative request sent from a 
VDE node to the VDE financial provider by the "adminis- 

35 trative request" invocation of BUDGET method 2250 shown 
in FIG. 42b. The "administrative response" invocation of 
BUDGET method 2250 results in the transmission of an 
administrative object from VDE financial provider to the 
VDE user node. Finally, the "administrative reply" invoca- 

40 tion of BUDGET method 2250 shown in FIG. 42d is 
performed at the user VDE node upon receipt of the admin- 
istrative object sent by the "administrative response" invo- 
cation of the method shown in FIG. 42c. 

In the preferred embodiment, the same BUDGET method 

45 2250 performs each of the four different step sequences 
shown in FIGS. 42a-42d. In the preferred embodiment, 
different event codes may be passed to the BUDGET method 
2250 to invoke these various different modes. Of course, it 
would be possible to use four separate BUDGET methods 

50 instead of a single BUDGET method with four different 
"dynamic personalities," but the preferred embodiment 
obtains certain advantages by using the same BUDGET 
method for each of these four types of invocations. 
Looking at FIG. 42a, the "use" invocation of BUDGET 

55 method 2250 first primes the Budget Audit Trail (blocks 
2252, 2254). It then obtains the DTD for the Budget UDE, 
which it uses to obtain and read the Budget UDE blocks 
2256-2262). BUDGET method 2250 in this "use" invoca- 
tion may then determine whether a Budget Audit date has 

60 expired, and terminate if it has ("yes" exit to decision block 
2264; blocks 2266, 2268). So long as the Budget Audit date 
has not expired, the method may then update the Budget 
using the atomic element and event counts (and possibly 
other information) (blocks 2270, 2272), and may then save 

65 a Budget User Audit record in a Budget Audit Trail UDE 
(blocks 2274, 2276) before terminating (at terminate point 
2278). 



"Use" Events use budget 

Request Events request more budget 
Processed by 

User Node request audit by auditor 

Request Process #1 

1480c request budget deletion 

request method updated 

request to change auditors 

request different audit 
interval 

request ability to provide 
budget copies 

request ability to 
distribute budget 

request account status 



Request New Method 
Request Method Update 

Request Method Deletion 

Response Events receive more budget 
Processed by 

User Node receive method update 

Request Process Receive auditor change 
1480C 

receive change to audit 
interval 

receive budget deletion 
provide audit to auditor 
#1 

provide audit to auditor 
#2 

receive account status 

Receive New 

Receive Method Update 

Receive More 

Sent Audit 

Perform Deletion 
"Distribute" Create New 

Events Provide More 

Audit 

Delete 

Reconcile 

Copy 
Distribute 

Method Modification 
Display Method 

"Request" Events Delete 

Processed by Get New 

Distributor Node Get More 

Request Process Get Updated 

1484B Get Audited 

"Response Provide New to user 
Events" 



Use budget. 

Request more money for 
budget 

Request that auditor #1 
audit the budget use. 
Request that budget be 
deleted from system. 
Update method used for 
auditing. 

Change from auditor 1 to 
auditor 2, or vice versa. 
Change time interval 
between audits. 
Request ability to 
provide copies of a 
budget. 

Request ability to 
distribute a budget to 
other users. 

Request information on 
current status of an 
account. 

Request new method. 
Request update of 
method. 

Request deletion of 
method. 

Allocate more money to 
budget. 

Update method. 
Change from one auditor 
to another. - 
Change interval between 
audits. 

Delete budget 
Forward audit 
information to 
auditor #1. 
Forward audit 
information to 
auditor #2. 

Provide account status. 
Receive new budget. 
Receive updated 
information. 

Receive more for budget 
Send audit information. 
Delete information. 
Create new budget. 
Provide more for budget. 
Perform audit 
Delete information. 
Reconcile budget and 
auditing. 
Copy budget 
Distribute budget 
Modify method. 
Display requested 
method. 

Delete information. 
Get new budget 
Get more for budget 
Get updated information. 
Get audit information. 
Provide new budget to 
user. 



03/04/2003, EAST Version: 1.03.0002 



5,892; 

183 

Looking at FIG. 42b, the first six steps (blocks 
2280-22 90) may be performed by the user VDE node in 
response to some user action (e.g., request to access new 
information, request for a new budget, etc.). This "admin- 
istrative request" invocation of BUDGET method 2250 may s 
prime an audit trail (blocks 2280, 2282). The method may 
then place a request for administrative processing of an 
appropriate Budget onto a request queue (blocks 2284, 
2286). Finally, the method may save appropriate audit trail 
information (blocks 2288, 2290). Sometime later, the user 10 
VDE node may prime a communications audit trail (blocks 
2292, 2294), and may then write a Budget Administrative 
Request into an administrative object (block 2296). This step 
may obtain information from the secure database as needed 
from such sources such as, for example, Budget UDE; 15 
Budget Audit Trail UDE(s); and Budget Administrative 
Request Record(s) (block 2298). 

Block 2296 may then communicate the administrative 
object to a VDE financial provider, or alternatively, block 
2296 may pass administrative object to a separate commu- 20 
nications process or method that arranges for such commu- 
nications to occur. If desired, method 2250 may then save a 
communications audit trail (blocks 2300, 2302) before ter- 
minating (at termination point 2304). 

FIG. 42c is a flowchart of an example of process control 25 
steps performed by the example of BUDGET method 2250 
provided by the preferred embodiment operating in an 
"administrative response" mode. Steps shown in FIG. 42c 
would, for example, be performed by a VDE financial 
provider who has received an administrative object contain- 30 
ing a Budget administrative request as created (and com- 
municated to a VDE administrator for example) by FIG. 42b 
(block 2296). 

Upon receiving the administrative object, BUDGET 
method 2250 at the VDE financial provider site may prime 35 
a budget communications and response audit trail (blocks 
2306, 2308), and may then unpack the administrative object 
and retrieve the budget requests), audit trail(s) and record(s) 
it contains (block 2310). This information retrieved from the 
administrative object may be written by the VDE financial 40 
provider into its secure database (block 2312). The VDE 
financial provider may then retrieve the budget request(s) 
and determine the response method it needs to execute to 
process the request (blocks 2314, 2316). BUDGET method 
2250 may send the evcnt(s) contained in the request record 45 
(s) to the appropriate response method and may generate 
response records and response requests based on the 
RESPONSE method (block 2318). The process performed 
by block 2318 may satisfy the budget request by writing 
appropriate new response records into the VDE financial 50 
provider's secure database (block 2320). BUDGET method 
2250 may then write these Budget administrative response 
records into an administrative object (blocks 2322, 2324), 
which it may then communicate back to the user node that 
initiated the budget request. BUDGET method 2250 may 55 
then save communications and response processing audit 
trail information into appropriate audit trail UDE(s) (blocks 
2326, 2328) before terminating (at termination point 2330). 

FIG. 42d is a flowchart of an example of program control 
steps performed by a representative example of BUDGET 60 
method 2250 operating in an "administrative reply" mode. 
Steps shown in FIG. 42d might be performed, for example, 
by a VDE user node upon receipt of an administrative object 
containing budget-related information. BUDGET method 
2250 may first prime a Budget administrative and commu- 65 
nications audit trail (blocks 2332, 2334). BUDGET method 
2250 may then extract records and requests from a received 
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administrative object and write the reply record to the VDE 
secure database (blocks 2336, 2338). The VDE user node 
may then save budget administrative and communications 
audit trail information in an appropriate audit trail UDE(s) 
(blocks 2340, 2341). 

Sometime later, the VDE user node may retrieve the reply 
record from the secure database and determine what method 
is required to process it (blocks 2344, 2346). The VDE user 
node may, optionally, prime an audit trail (blocks 2342, 
2343) to record the results of the processing of the reply 
event. The BUDGET method 2250 may then send event(s) 
contained in the reply record(s) to the REPLY method, and 
may generate/update the secure database records as neces- 
sary to, for example, insert new budget records, delete old 
budget records and/or apply changes to budget records 
(blocks 2348, 2350). BUDGET method 2250 may then 
delete the reply record from the secure data base (blocks 
2352, 2353) before writing the audit trail (if required) 
(blocks 2354m 2355) terminating (at terminate point 2356). 
B. REGISTER 

FIGS. 43a-43d are flowcharts of an example of program 
control steps performed by a representative example of a 
REGISTER method 2400 provided by the preferred embodi- 
ment. In this example, the REGISTER method 2400 per- 
forms the example steps shown in FIG. 43a when operating 
in a "use" mode, performs the example steps shown in FIG. 
43b when operating in an "administrative request" mode, 
performs the steps shown in FIG. 43c when operating in an 
"administrative response" mode, and performs the steps 
shown in FIG. 43c/ when operating in an "administrative 
reply" mode. 

The steps shown in FIG. 43a may be, for example, 
performed at a user VDE node in response to some action by 
or on behalf of the user. For example the user may ask to 
access an object that has not yet been (or is not now) 
properly registered to her. In response to such a user request, 
the REGISTER method 2400 may prime a Register Audit 
Trail UDE (blocks 2402, 2404) before determining whether 
the object being requested has already been registered 
(decision block 2406). If the object has already been regis- 
tered ("yes" exit to decision block 2406), the REGISTER 
method may terminate (at termination point 2408). If the 
object is not already registered ("no" exit to decision block 
2406), then REGISTER method 2400 may access the VDE 
node secure database PERC 808 and/or Register MDE 
(block 2410). REGISTER method 2400 may extract an 
appropriate Register Record Set from this PERC 808 and/or 
Register MDE (block 2412), and determine whether all of 
the required elements are present that are needed to register 
the object (decision block 2414). If some piece(s) is missing 
("no" exit to decision block 2414), REGISTER method 
2400 may queue a Register request record to a communi- 
cation manager and then suspend the REGISTER method 
until the queued request is satisfied (blocks 2416, 2418). 
Block 2416 may have the effect of communicating a register 
request to a VDE distributor, for example. When the request 
is satisfied and the register request record has been received 
(block 2420), then the test of decision block 2414 is satisfied 
("yes" exit to decision block 2414), and REGISTER method 
2400 may proceed. At this stage, the REGISTER method 
2400 may allow the user to select Register options from the 
set of method options allowed by PERC 808 accessed at 
block 2410 (block 2422). As one simple example, the PERC 
808 may permit the user to pay by VISA or MasterCard but 
not by American Express; block 2422 may display a prompt 
asking the user to select between paying using her VISA 
card and paying using her MasterCard (block 2424). The 
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REGISTER method 2400 preferably validates the user 
selected registration options and requires the user to select 
different options if the initial user options were invalid 
(block 2426, "no" exit to decision block 2428). Once the 
user has made all required registration option selections and 
those selections have been validated ("yes" exit to decision 
block 2428), the REGISTER method 2400 may write an 
User Registration Table (URT) corresponding to this object 
and this user which embodies the user registration selections 
made by the user along with other registration information 
required by PERC 808 and/or the Register MDE (blocks 
2430, 2432). REGISTER method 2400 may then write a 
Register audit record into the secure database (blocks 2432, 
2434) before terminating (at terminate point 2436). 

FIG. 43b shows an example of an "administrative 
request" mode of REGISTER method 2400. This Adminis- 
trative Request Mode may occur on a VDE user system to 
generate an appropriate administrative object for communi- 
cation to a VDE distributor or other appropriate VDE 
participant requesting registration information. Thus, for 
example, the steps shown in FIG. 436 may be performed as 
part of the "queue register request record" block 2416 shown 
in FIG. 43a. To make a Register administrative request, 
REGISTER method 2400 may first prime a communications 
audit trail (blocks 2440, 2442), and then access the secure 
database to obtain data about registration (block 2444). This 
secure database access may, for example, allow the owner 
and/or publisher of the object being registered to find out 
demographic, user or other information about the user. As a 
specific example, suppose that the object being registered is 
a spreadsheet software program. The distributor of the object 
may want to know what other software the user has regis- 
tered. For example, the distributor may be willing to give 
preferential pricing if the user registers a "suite" of multiple 
software products distributed by the same distributor. Thus, 
the sort of information solicited by a "user registration" card 
enclosed with most standard software packages may be 
solicited and automatically obtained by the preferred 
embodiment at registration time. In order to protect the 
privacy rights of the user, REGISTER method 2400 may 
pass such user-specific data through a privacy filter that may 
be at least in part customized by the user so the user can 
prevent certain information from being revealed to the 
outside world (block 2446). The REGISTER method 2400 
may write the resulting information along with appropriate 
Register Request information identifying the object and 
other appropriate parameters into an administrative object 
(blocks 2448, 2450). REGISTER method 2400 may then 
pass this administrative object to a communications handler. 
REGISTER method 2400 may then save a communications 
audit trail (blocks 2452, 2454) before terminating (at termi- 
nate point 2456). 

FIG. 43c includes REGISTER method 2400 steps that 
may be performed by a VDE distributor node upon receipt 
of Register Administrative object sent by block 2448, FIG. 
43b. REGISTER method 2400 in this "administrative 
response" mode may prime appropriate audit trails (blocks 
2460, 2462), and then may unpack the received administra- 
tive object and write the associated register requests) con- 
figuration information into the secure database (blocks 2464, 
2466). REGISTER method 2400 may then retrieve the 
administrative request from the secure database and deter- 
mine which response method to run to process the request 
(blocks 2468, 2470). If the user fails to provide sufficient 
information to register the object, REGISTER method 2400 
may fail (blocks 2472, 2474). Otherwise, REGISTER 
method 2400 may send event(s) contained in the appropriate 
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request record(s) to the appropriate response method, and 
generate and write response records and response requests 
(e.g., PERC(s) and/or UDEs) to the secure database (blocks 
2476, 2478). REGISTER method 2400 may then write the 

5 appropriate Register administrative response record into an 
administrative object (blocks 2480, 2482). Such information 
may include, for example, one or more replacement PERC 
(s) 808, methods, UDE(s), etc. (block 2482). This enables, 
for example, a distributor to distribute limited right permis- 

10 sions giving users only enough information to register an 
object, and then later, upon registration, replacing the lim- 
ited right permissions with wider permissioning scope grant- 
ing the user more complete access to the objects. REGIS- 
TER method 2400 may then save the communications and 

15 response processing audit trail (blocks 2484, 2486), before 
terminating (at terminate point 2488). 

FIG. 43d shows steps that may be performed by the VDE 
user node upon receipt of the administrative object 
generated/transmitted by FIG. 43c block 2480. The steps 

20 shown in FIG. 43d are very similar to those shown in FIG. 
42d for the BUDGET method administrative reply process. 
C. AUDIT 

FIGS. 44a-44c are flowcharts of examples of program 
control steps performed by a representative example of an 

25 AUDIT method 2520 provided by the preferred embodi- 
ment. As in the examples above, the AUDIT method 2520 
provides three different operational modes in this preferred 
embodiment example: FIG. 44a shows the steps performed 
by the AUDIT method in an "administrative request" mode; 

30 FIG. 44Z> shows steps performed by the method in the 
"administrative response" mode; and FIG. 44c shows the 
steps performed by the method in an "administrative reply" 
mode. 

The AUDIT method 2520 operating in the "administrative 

35 request" mode as shown in FIG. 44a is typically performed, 
for example, at a VDE user node based upon some request 
by or on behalf of the user. For example, the user may have 
requested an audit, or a timer may have expired that initiates 
communication of audit information to a VDE content 

40 provider or other VDE participant. In the preferred 
embodiment, different audits of the same overall process 
may be performed by different VDE participants. A particu- 
lar "audit" method 2520 invocation may be initiated for any 
one (or all) of the involved VDE participants. Upon invo- 

45 cation of AUDIT method 2520, the method may prime an 
audit administrative audit trail (thus, in the preferred 
embodiment, the audit processing may itself be audited) 
(blocks 2522, 2524). The AUDIT method 2520 may then 
queue a request for administrative processing (blocks 2526, 

50 2528), and then may save the audit administrative audit trail 
in the secure database (blocks 2530, 2532). Sometime later, 
AUDIT method 2520 may prime a communications audit 
trail (blocks 2534, 2536), and may then write Audit Admin- 
istrative Requests) into one or more administrative objects) 

55 based on specific UDE, audit trail UDE(s), and/or adminis- 
trative record(s) stored in the secure database (blocks 2538, 
2540). The AUDIT method 2520 may then save appropriate 
information into the communications audit trail (blocks 
2542, 2544) before terminating (at terminate point 2546). 

60 FIG. 446 shows example steps performed by a VDE 
content provider, financial provider or other auditing VDE 
node upon receipt of the administrative object generated and 
communicated by FIG. 44a block 2538. The AUDIT method 
2520 in this "administrative response" mode may first prime 

65 an Audit communications and response audit trail (blocks 
2550, 2552), and may then unpack the received administra- 
tive object and retrieve its contained Audit requests) audit 
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trail(s) and audit record(s) for storage into the secured is to be metered based upon number of pages read, then user 

database (blocks 2554, 2556). AUDIT method 2520 may request "events" for reading less than a page of information 

then retrieve the audit requests) from the secure database may be ignored. In another example, if a system event 

and determine the response method to run to process the represents a request to read a certain number of bytes, and 

request (blocks 2558, 2560). AUDIT method 2520 may at 5 ^ EVENT method 1000 is part of a control process 

this stage send events) contained in the request record(s) to designed to meter paragraphs, then the EVENT method may 

the appropriate response method, and generate response evaluate the read request to determine how many paragraphs 

record(s) and requests based on this method (blocks 2562, are presented in the bytes requested This process may 

2564). The processing block 2562 may involve a commu- mvolv ? "ft?"* * ° *° dwcussed m 

• / 4 A. . .j u more detail below, 

motion to the outside ^wor d. 10 EVENT method 402 filters out events that are not sig- 

For example, AUDIT method 2520 at this point could call nificaQt ^ d iQ ^ dfic method 
an external process to perform for example, an electronic EVENT method 402 may pass on qualified events to a 
funds transfer against the user s bank account or some other METER process 1404, which meters or discards the event 
bank account. The AUDIT administrative response can, if bascd on its own par ticular criteria, 
desired, call an external process that interfaces VDE to one 15 j n addition, the preferred embodiment provides an opti- 
or more existing computer systems. Hie external process mization called "precheck." EVENT method/process 402 
could be passed the user's account number, PIN, dollar ma y perform this "precheck" based on metering, billing and 
amount, or any other information configured in, or associ- budget information to determine whether processing based 
ated with, the VDE audit trail being processed. The external on an event will be allowed. Suppose, for example, that the 
process can communicate with non-VDE hosts and use the 20 user has already exceeded her budget with respect to access- 
information passed to it as part of these communications. ing certain information content so that no further access is 
For example, the external process could generate automated permitted. Although BUDGET method 408 could make this 
clearinghouse (ACH) records in a file for submittal to a determination, records and processes performed by BUD- 
bank. This mechanism would provide the ability to auto- GET method 404 and/or BILLING method 406 might have 
matically credit or debit a bank account in any financial 25 to be "undone" to, for example, prevent the user from being 
institution. The same mechanism could be used to commu- charged for an access that was actually denied. It may be 
nicate with the existing credit card (e.g. VISA) network by more efficient to perform a "precheck** within EVENT 
submitting VDE based charges against the charge account. method 402 so that fewer transactions have to be "undone." 

Once the appropriate Audit response record(s) have been METER method 404 may store an audit record in a meter 

generated, AUDIT method 2520 may write an Audit admin- 30 "trail" UDE 1200, for example, and may also record infor- 

istrative record(s) into an administrative object for commu- mation related to the event in a meter UDE 1200. For 

nication back to the VDE user node that generated the Audit example, METER method 404 may increment or decrement 

request (blocks 2566, 2568). The AUDIT method 2520 may a "meter" value within a meter UDE 1200 each time content 

then save communications and response processing audit is accessed. The two different data structures (meter UDE 

information in appropriate audit trail(s) (blocks 2570, 2572) 35 and meter trail UDE) may be maintained to permit record 

before terminating (at terminate point 2574). keeping for reporting purposes to be maintained separately 

FIG. 44c shows an example of steps that may be per- from record keeping for internal operation purposes, for 

formed by the AUDIT method 2520 back at the VDE user example. 

node upon receipt of the administrative object generated and Once the event is metered by METER method 404, the 

sent by FIG. 446, block 2566. The steps 2580-2599 shown 40 metered event may be processed by a BILLING method 406. 

in FIG. 44c are similar to the steps shown in FIG. 43d for the BILLING method 406 determines how much budget is 

REGISTER method 2400 in the "administrative reply" consumed by the event, and keeps records that are useful for 

mode. Briefly, these steps involve receiving and extracting reconciliation of meters and budgets. Thus, for example, 

appropriate response records from the administrative object BILLING method 406 may read budget information from a 

(block 2584), and then processing the received information 45 budget UDE, record billing information in a billing UDE, 

appropriately to update secure database records and perform and write one or more audit records in a billing trail UDE. 

any other necessary actions (blocks 2595, 2596). While some billing trail information may duplicate meter 

and/or budget trail information, the billing trail information 

Examples of Event-Driven Content-Based Methods ^ useful( for example, to allow a content creator 102 to 

VDE methods 1000 are designed to provide a very 50 expect a payment of a certain size, and serve as a reconcih- 

flexible and highly modular approach to secure processing. ation check t0 reconcile meter trail information sent to 

A complete VDE process to service a "use event" may creator 102 Wlth bud 8 et trail information sent to, for 

typically be constructed as a combination of methods 1000. example, an independent budget provider. 

As one example, the typical process for reading content or BILLING method 406 may then pass the event on to a 

other information from an object 300 may involve the 55 BUDGET method 408. BUDGET method 408 sets limits 

following methods: anc * records transactional information associated with those 

ct ^ KfT ./ . limits. For example, BUDGET method 408 may store bud- 

an EVENT method . - f ' . , . , / ... 

get information in a budget UDE, and may store an audit 

a METER method record in a budget trail BUDGET method 408 may 

a BILLING method 60 rcsu i t ^ a "budget remaining" field in a budget UDE being 

a BUDGET method. decremented by an amount specified by BILLING method 

FIG. 45 is an example of a sequential series of methods 406. 

performed by VDE 100 in response to an event. In this The information content may be released, or other action 

example, when an event occurs, an EVENT method 402 may taken, once the various methods 402, 404, 406, 408 have 

"qualify" the event to determine whether it is significant or 65 processed the event. 

not. Not all events are significant. For example, if the As mentioned above, PERCs 808 in the preferred embodi- 

EVENT method 1000 in a control process dictates that usage ment may be provided with "control methods" that in effect 
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"oversee" performance of the other required methods in a ERROR method 

control process. FIG. 46 shows how the required methods/ DECRYPT method 

processes 402, 404 406 and 408 of FIG 45 can be ENCR YPT method 

organized and controlled by a control method 410. Control n _ CTDnv 

method 410 may call, dispatch events, or otherwise invoke 5 Vhi > 1KOY 001116131 method 

the other methods 402, 404, 406, 408 and otherwise super- INFORMATION method 

vise the processing performed in response to an "event." OBSCURE method 

Control methods operate at the level of control sets 906 FINGERPRINT method 

within PERCs 808. They provide structure, logic, and flow EVENT method 

of control between disparate acquired methods 1000. This 10 rnwrcrwr 

mechanism permits the content provider to create any me 

desired chain of processing, and also allows the specific EXTRACT method 

chain of processing to be modified (within permitted limits) EMBED method 

by downstream redistributors. This control structure concept METER method 
provides great flexibility. 15 

FIG. 47 shows an example of an "aggregate" method 412 
which collects METER method 404, BUDGET method 406 

and BILLING method 408 into an "aggregate" processing BILLING method 

flow. Aggregate method 412 may, for example, combine AUDIT method 

various elements of metering, budgeting and billing into a 20 An ACCESS method may be used to physically access 

single method 1000. Aggregate method 412 may provide content associated with an opened container (the content can 

increased efficiency as a result of processing METER be anywhere). A PANIC method may be used to disable at 

method 404, BUDGET method 406 and BILLING method least a portion of the VDE node if a security violation is 

408 aggregately, but may decrease flexibility because of detected. An ERROR method may be used to handle error 

decreased modularity. 25 conditions. A DECRYPT method is used to decrypt 

Many different methods can be in effect simultaneously. encrypted information. An ENCRYPT method is used to 

FIG. 48 shows an example of preferred embodiment event encrypt information. A DESTROY content method is used to 

processing using multiple METER methods 404 and mul- destroy the ability to access specific content within a con- 

tiple BUDGET methods 1408. Some events may be subject tainer. An INFORMATION method is used to provide public 

to many different required methods operating independently 30 information about the contents of a container. An 

or cumulatively. For example, in the example shown in FIG. OBSCURE method is used to devalue content read from an 

48, meter method 404a may maintain meter trail and meter opened container (e.g., to write the word "SAMPLE" over 

information records that are independent from the meter trail a displayed image). A FINGERPRINT method is used to 

and meter information records maintained by METER mark content to show who has released it from the secure 

method 404b. Similarly, BUDGET method 408a may main- 35 container. An event method is used to convert events into 

tain records independently of those records maintained by different events for response by other methods. 
BUDGET method 408Z>. Some events may bypass BILLING 

method 408 while nevertheless being processed by meter Open 

method 404a and BUDGET method 408a. A variety of cjn A a - a u -* c 1 c c j u -r 

. . ... 7 FIG. 49 is a flowchart of an example of preferred embodi- 

different variations are possible. 40 , . 1 . * 1 # AnnM 

r ment process control steps for an example of an OPEN 

REPRESENTATIVE EXAMPLES OF VDE method 1500. Different OPEN methods provide different 

METHODS detailed steps. However, the OPEN method shown in FIG. 

49 is a representative example of a relatively full-featured 
Although methods 1000 can have virtually unlimited "open" method provided by the preferred embodiment. FIG. 
vanety and some may even be user-defined, certain basic 45 ^ show$ a macroscopic vicw of mc 0PEN mcthod FIGS 
use type methods are preferably used in the preferred 49^9/ are together an example of detailed program con- 
embodiment to control most of the more fundamental [object trolled st performed t0 implement the method shown in 
manipulation and other functions provided by VDE 100. For pjQ 49 

example, the following high level methods would typically ™ AnrxT . , ... (( A „ 

h, nmvided for oh«rf m.ninnl.rinn- 50 ^ 0PEN method P TOCeSS StartS wth aD °P eD eVent " 



be provided for object manipulation: 50 
OPEN method 



This open event may be generated by a user application, an 
operating system intercept or various other mechanisms for 

READ method capturing or intercepting control. For example, a user appli- 

WRITE method cation may issue a request for access to a particular content 

CLOSE method. 55 stored within the VDE container. As another example, 

An OPEN method is used to control opening a container another method may issue a command, 

so its contents may be accessed. A READ method is used to In the example shown, the open event is processed by a 

control the access to contents in a container. A WRITE control method 1502. Control method 1502 may call other 

method is used to control the insertion of contents into a methods to process the event. For example, control method 

container. A CLOSE method is used to close a container that 60 1502 may call an EVENT method 1504, a METER method 

has been opened. 1506, a BILLING method 1508, and a BUDGET method 

Subsidiary methods are provided to perform some of the 1510. Not all OPEN control methods necessarily call of 

steps required by the OPEN, READ, WRITE and/or CLOSE these additional methods, but the OPEN method 1500 

methods. Such subsidiary methods may include the follow- shown in FIG. 49 is a representative example. 

m S : 65 Control method 1502 passes a description of the open 

ACCESS method event to EVENT method 1504. EVENT method 1504 may 

PANIC method determine, for example, whether the open event is permitted 
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and whether the open event is significant in the sense that it 
needs to be processed by METER method 1506, BILLING 
method 1508, and/or BUDGET method 1510. EVENT 
method 1504 may maintain audit trail information within an 
audit trail UDE, and may determine permissions and sig- 
nificance of the event by using an Event Method Data 
Element (MDE). EVENT method 1504 may also map the 
open event into an "atomic element" and count that may be 
processed by METER method 1506, BILLING method 
1508, and/or BUDGET method 1510. 

In OPEN method 1500, once EVENT method 1504 has 
been called and returns successfully, control method 1502 
then may call METER method 1506 and pass the METER 
method, the atomic element and count returned by EVENT 
method 1504. METER method 1506 may maintain audit 
trail information in a METER method Audit Trail UDE, and 
may also maintain meter information in a METER method 
UDE. In the preferred embodiment, METER method 1506 
returns a meter value to control method 1502 assuming 
successful completion. 

In the preferred embodiment, control method 1502 upon 
receiving an indication that METER method 1506 has 
completed successfully, then calls BILLING method 1508. 
Control method 1502 may pass to BILLING method 1508 
the meter value provided by METER method 1506. BILL- 
ING method 1508 may read and update billing information 
maintained in a BILLING method map MDE, and may also 
maintain and update audit trail in a BILLING method Audit 
Trail UDE. BILLING method 1508 may return a billing 
amount and a completion code to control method 1502 

Assuming BILLING method 1508 completes 
successfully, control method 1502 may pass the billing value 
provided by BILLING method 1508 to BUDGET method 
1510. BUDGET method 1510 may read and update budget 
information within a BUDGET method UDE, and may also 
maintain audit trail information in a BUDGET method Audit 
Trail UDE. BUDGET method 1510 may return a budget 
value to control method 1502, and may also return a 
completion code indicating whether the open event exceeds 
the user's budget (for this type of event). 

Upon completion of BUDGET method 1510, control 
method 1502 may create a channel and establish read/use 
control information in preparation for subsequent calls to the 
READ method. 

FIGS. 49a-49f are a more detailed description of the 
OPEN method 1500 example shown in FIG. 49. Referring to 
FIG. 49a, in response to an open event, control method 1502 
first may determine the identification of the object to be 
opened and the identification of the user that has requested 
the object to be opened (block 1520). Control method 1502 
then determines whether the object to be opened is regis- 
tered for this user (decision block 1522). It makes this 
determination at least in part in the preferred embodiment by 
reading the PERC 808 and the User Rights Table (URT) 
element associated with the particular object and particular 
user determined by block 1520 (block 1524). If the user is 
not registered for this particular object ("no" exit to decision 
block 1522), then control method 1502 may call the REG- 
ISTER method for the object and restart the OPEN method 
1500 once registration is complete (block 1526). The REG- 
ISTER method block 1526 may be an independent process 
and may be time independent. It may, for example, take a 
relatively long time to complete the REGISTER method 
(say if the VDE distributor or other participant responsible 
for providing registration wants to perform a credit check on 
the user before registering the user for this particular object). 



10 



15 



20 



25 



30 



35 



45 



50 



55 



60 



65 



Assuming the proper URT for this user and object is 
present such that the object is registered for this user ("yes" 
exit to decision block 1522), control method 1502 may 
determine whether the object is already open for this user 
(decision block 1528). This test may avoid creating a 
redundant channel for opening an object that is already open. 
Assuming the object is not already open ("no" exit to 
decision block 1528), control method 1502 creates a channel 
and binds appropriate open control elements to it (block 
1530). It reads the appropriate open control elements from 
the secure database (or the container, such as, for example, 
in the case of a travelling object), and "binds" or "links" 
these particular appropriate control elements together in 
order to control opening of the object for this user. Thus, 
block 1530 associates an event with one or more appropriate 
method core(s), appropriate load modules, appropriate User 
Data Elements, and appropriate Method Data Elements read 
from the secure database (or the container) (block 1532). At 
this point, control method 1502 specifies the open event 
(which started the OPEN method to begin with), the object 
ID and user ID (determined by block 1520), and the channel 
ID of the channel created by block 1530 to subsequent 
EVENT method 1504, METER method 1506, BILLING 
method 1508 and BUDGET method 1510 to provide a 
secure database "transaction" (block 1536). Before doing so, 
control method 1502 may prime an audit process (block 

1533) and write audit information into an audit UDE (block 

1534) so a record of the transaction exists even if the 
transaction fails or is interfered with. 

The detail steps performed by EVENT method 1504 are 
set forth on FIG. 49b. EVENT method 1504 may first prime 
an event audit trail if required (block 1538) which may write 
to an EVENT Method Audit Trail UDE (block 1540). 
EVENT method 1504 may then perform the step of mapping 
the open event to an atomic element number and event count 
using a map MDE (block 1542). The EVENT method map 
MDE may be read from the secure database (block 1544). 
This mapping process performed by block 1542 may, for 
example, determine whether or not the open event is 
meterable, billable, or budgetablc, and may transform the 
open event into some discrete atomic element for metering, 
billing and/or budgeting, As one example, block 1542 might 
perform a one-to-one mapping between open events and 
"open" atomic elements, or it may only provide an open 
atomic element for every fifth time that the object is opened. 
The map block 1542 preferably returns the open event, the 
event count, the atomic element number, the object ID, and 
the user ID. This information may be written to the EVENT 
method Audit Trail UDE (block 1546, 1548). In the pre- 
ferred embodiment, a test (decision block 1550) is then 
performed to determine whether the EVENT method failed. 
Specifically, decision block 1550 may determine whether an 
atomic element number was generated. If no atomic element 
number was generated (e.g., meaning that the open event is 
not significant for processing by METER method 1506, 
BILLING method 1508 and/or BUDGET method 1510), 
then EVENT method 1504 may return a "fail" completion 
code to control method 1502 ("no" exit to decision block 
1550). 

Control method 1502 tests the completion code returned 
by EVENT method 1504 to determine whether it failed or 
was successful (decision block 1552). If the EVENT method 
failed ("no" exit to decision block 1552), control method 
1502 may "roll back" the secure database transaction (block 
1554) and return itself with an indication that the OPEN 
method failed (block 1556). In this context, "rolling back" 
the secure database transaction means, for example, "undo- 
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ing" the changes made to audit trail UDE by blocks 1540, 
1548. However, this "roll back" performed by block 1554 in 
the preferred embodiment does not "undo" the changes 
made to the control method audit UDE by blocks 1532, 
1534. 

Assuming the EVENT method 1504 completed 
successfully, control method 1502 then calls the METER 
method 1506 shown on FIG. 49c. In the preferred 
embodiment, METER method 1506 primes the meter audit 
trail if required (block 1558), which typically involves 
writing to a METER method audit trail UDE (block 1560). 
METER method 1506 may then read a METER method 
UDE from the secure database (block 1562), modify the 
meter UDE by adding an appropriate event count to the 
meter value contained in the meter UDE (block 1564), and 
then writing the modified meter UDE back to the secure 
database (block 1562). In other words, block 1564 may read 
the meter UDE, increment the meter count it contains, and 
write the changed meter UDE back to the secure database. 
In the preferred embodiment, METER method 1506 may 
then write meter audit trail information to the METER 
method audit trail UDE if required (blocks 1566, 1568). 
METER method 1506 preferably next performs a test to 
determine whether the meter increment succeeded (decision 
block 1570). METER method 1506 returns to control 
method 1502 with a completion code (e.g., succeed or fail) 
and a meter value determined by block 1564. 

Control method 1502 tests whether the METER method 
succeeded by examining the completion code, for example 
(decision block 1572). If the METER method failed ("no" 
exit to decision block 1572), then control method 1502 "rolls 
back" a secure database transaction (block 1574), and 
returns with an indication that the OPEN method failed 
(block 1576). Assuming the METER method succeeded 
("yes" exit to decision block 1572), control method 1502 
calls the BILLING method 1508 and passes it the meter 
value provided by METER method 1506. 

An example of steps performed by BILLING method 
1508 is set forth in FIG. 49d BILLING method 1508 may 
prime a billing audit trail if required (block 1578) by writing 
to a BILLING method Audit Trail UDE within the secure 
database (block 1580). BILLING method 1508 may then 
map the atomic element number, count and meter value to a 
billing amount using a BILLING method map MDE read 
from the secure database (blocks 1582, 1584). Providing an 
independent BILLING method map MDE containing, for 
example, price list information, allows separately deliver- 
able pricing for the billing process. The resulting billing 
amount generated by block 1582 may be written to the 
BILLING method Audit Trail UDE (blocks 1586, 1588), and 
may also be returned to control method 1502. In addition, 
BILLING method 1508 may determine whether a billing 
amount was properly selected by block 1582 (decision block 
1590). In this example, the test performed by block 1590 
generally requires more than mere examination of the 
returned billing amount, since the billing amount may be 
changed in unpredictable ways as specified by BILLING 
method map MDE. Control then returns to control method 
1502, which tests the completion code provided by BILL- 
ING method 1508 to determine whether the BILLING 
method succeeded or failed (block 1592). If the BILLING 
method failed ("no" exit to decision block 1592), control 
method 1502 may "roll back" the secure database transac- 
tion (block 1594), and return an indication that the OPEN 
method failed (block 1596). Assuming the test performed by 
decision block 1592 indicates that the BILLING method 
succeeded ("yes" exit to decision block 1592), then control 
method 1502 may call BUDGET method 1510. 
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Other BILLING methods may use site, user and/or usage 
information to establish, for example, pricing information. 
For example, information concerning the presence or 
absence of an object may be used in establishing "suite" 

5 purchases, competitive discounts, etc. Usage levels may be 
factored into a BILLING method to establish price breaks 
for different levels of usage. A currency translation feature of 
a BILLING method may allow purchases and/or pricing in 
many different currencies. Many other possibilities exist for 

10 determining an amount of budget consumed by an event that 
may be incorporated into BILLING methods. 

An example of detailed control steps performed by BUD- 
GET method 1510 is set forth in FIG. 49<?. BUDGET 
method 1510 may prime a budget audit trail if required by 

15 writing to a budget trail UDE (blocks 1598, 1600). BUD- 
GET method 1510 may next perform a billing operation by 
adding a billing amount to a budget value (block 1602). This 
operation may be performed, for example, by reading a 
BUDGET method UDE from the secure database, modify - 

20 ing it, and writing it back to the secure database (block 
1604). BUDGET method 1510 may then write the budget 
audit trail information to the BUDGET method Audit Trail 
UDE (blocks 1606, 1608). BUDGET method 1510 may 
fiaally, in this example, determine whether the user has run 

25 out of budget by determining whether the budget value 
calculated by block 1602 is out of range (decision block 
1610). If the user has run out of budget ("yes" exit to 
decision block 1610), the BUDGET method 1510 may 
return a "fail completion" code to control method 1502. 

30 BUDGET method 1510 then returns to control method 1502, 
which tests whether the BUDGET method completion code 
was successful (decision block 1612). If the BUDGET 
method failed ("no" exit to decision block 1612), control 
method 1502 may "roll back" the secure database transac- 

35 tion and itself return with an indication that the OPEN 
method failed (blocks 1614, 1616). Assuming control 
method 1502 determines that the BUDGET method was 
successful, the control method may perform the additional 
steps shown on FIG. 49/ For example, control method 1502 

40 may write an open audit trail if required by writing audit 
information to the audit UDE that was primed at block 1532 
(blocks 1618, 1620). Control method 1502 may then estab- 
lish a read event processing (block 1622), using the User 
Right Table and the PERC associated with the object and 

45 user to establish the channel (block 1624). This channel may 
optionally be shared between users of the VDE node 600, or 
may be used only by a specified user. 

Control method 1502 then, in the preferred embodiment, 
tests whether the read channel was established successfully 

50 (decision block 1626). If the read channel was not success- 
fully established ("no" exit to decision block 1626), control 
method 1502 "rolls back" the secured database transaction 
and provides an indication that the OPEN method failed 
(blocks 1628, 1630). Assuming the read channel was suc- 

55 cessfully established ("yes" exit to decision block 1626), 
control method 1502 may "commit" the secure database 
transaction (block 1632). This step of "committing" the 
secure database transaction in the preferred embodiment 
involves, for example, deleting intermediate values associ- 

60 ated with the secure transaction that has just been performed 
and, in one example, writing changed UDEs and MDEs to 
the secure database. It is generally not possible to "roll back" 
a secure transaction once it has been committed by block 
1632. Then, control method 1502 may "tear down" the 

65 channel for open processing (block 1634) before terminating 
(block 1636). In some arrangements, such as multi-tasking 
VDE node environments, the open channel may be con- 
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stantly maintained and available for use by any OPEN 
method that starts. In other implementations, the channel for 
open processing may be rebuilt and restarted each time an 
OPEN method starts. 

Read 5 

FIG. 50, 50fl-50/ show examples of process control steps 
for performing a representative example of a READ method 
1650. Comparing FIG. 50 with FIG. 49 reveals that the same 
overall high level processing may typically be performed for \q 
READ method 1650 as was described in connection with 
OPEN method 1500. Thus, READ method 1650 may call a 
control method 1652 in response to a read event, the control 
method in turn invoking an EVENT method 1654, a 
METER method 1656, a BILLING method 1658 and a 15 
BUDGET method 1660. In the preferred embodiment, 
READ control method 1652 may request methods to fin- 
gerprint and/or obscure content before releasing the 
decrypted content. 

FIGS. 50a-50<? are similar to FIGS. 49a~49e. Of course, 20 
even though the same user data elements may be used for 
both the OPEN method 1500 and the READ method 1650, 
the method data elements for the READ method may be 
completely different, and in addition, the user data elements 
may provide different auditing, metering, billing and/or 25 
budgeting criteria for read as opposed to open processing. 

Referring to FIG. 5% the READ control method 1652 
must determine which key to use to decrypt content if it is 
going to release decrypted content to the user (block 1758). 
READ control method 1652 may make this key determina- 
tion based, in part, upon the PERC 808 for the object (block 
1760). READ control method 1652 may then call an 
ACCESS method to actually obtain the encrypted content to 
be decrypted (block 1762). The content is then decrypted 
using the key determined by block 1758 (block 1764). 35 
READ control method 1652 may then determine whether a 
"fingerprint" is desired (decision block 1766). If fingerprint- 
ing of the content is desired ("yes" exit of decision block 
1766), READ control method 1652 may call the FINGER- 
PRINT method (block 1768). Otherwise, READ control 40 
method 1652 may determine whether it is desired to obscure 
the decrypted content (decision block 1770). If so, READ 
control method 1652 may call an OBSCURE method to 
perform this function (block 1772). Finally, READ control 
method 1652 may commit the secure database transaction 45 
(block 1774), optionally tear down the read channel (not 
shown), and terminate (block 1776). 

Write 

FIGS. 51, 51fl-51/are flowcharts of examples of process 50 
control steps used to perform a representative example of a 
WRITE method 1780 in the preferred embodiment. WRITE 
method 1780 uses a control method 1782 to call an EVENT 
method 1784, METER method 1786, BILLING method 
1788, and BUDGET method 1790 in this example. Thus, 55 
writing information into a container (either by overwriting 
information already stored in the container or adding new 
information to the container) in the preferred embodiment 
may be metered, billed and/or budgeted in a manner similar 
to the way opening a container and reading from a container 60 
can be metered, billed and budgeted. As shown in FIG. 51, 
the end result of WRITE method 1780 is typically to encrypt 
content, update the container table of contents and related 
information to reflect the new content, and write the content 
to the object. 65 

FIG. 51a for the WRITE control method 1782 is similar 
to FIG. 49a and FIG. 50a for the OPEN control method and 



the READ control method, respectively. However, FIG. Sib 
is slightly different from its open and read counterparts. In 
particular, block 1820 is performed if the WRITE EVENT 
method 1784 fails. This block 1820 updates the EVENT 
method map MDE to reflect new data. This is necessary to 
allow information written by block 1810 to be read by FIG. 
516 READ method block 1678 based on the same (but now 
updated) EVENT method map MDE. 

Looking at FIG. 51/ once the EVENT, METER, BILL- 
ING and BUDGET methods have returned successfully to 
WRITE control method 1782, the WRITE control method 
writes audit information to Audit UDE (blocks 1890, 1892), 
and then determines (based on the PERC for the object and 
user and an optional algorithm) which key should be used to 
encrypt the content before it is written to the container 
(blocks 1894, 1896). CONTROL method 1782 then encrypts 
the content (block 1898) possibly by calling an ENCRYPT 
method, and writes the encrypted content to the object 
(block 1900). CONTROL method 1782 may then update the 
table of contents (and related information) for the container 
to reflect the newly written information (block 1902), com- 
mit the secure database transaction (block 1904), and return 
(block 1906). 

Close 

FIG. 52 is a flowchart of an example of process control 
steps to perform a representative example of a CLOSE 
method 1920 in the preferred embodiment. CLOSE method 
1920 is used to close an open object. In the preferred 
embodiment, CLOSE method 1920 primes an audit trail and 
writes audit information to an Audit UDE (blocks 1922, 
1924). CLOSE method 1920 then may destroy the current 
channels) being used to support and/or process one or more 
open objects (block 1926). As discussed above, in some 
(e.g., multi-user or multi-tasking) installations, the step of 
destroying a channel is not needed because the channel may 
be left operating for processing additional objects for the 
same or different users. CLOSE method 1920 also releases 
appropriate records and resources associated with the object 
at this time (block 1926). The CLOSE method 1920 may 
then write an audit trail (if required) into an Audit UDE 
(blocks 1928, 1930) before completing. 

Event 

FIG. 53a is a flowchart of example process control steps 
provided by a more general example of an EVENT method 
1940 provided by the preferred embodiment. Examples of 
EVENT methods are set forth in FIGS. 49b, SOb and Sib and 
are described above. EVENT method 1940 shown in FIG. 
53a is somewhat more generalized than the examples above. 
Like the EVENT method examples above, EVENT method 
1940 receives an identification of the event along with an 
event count and event parameters. EVENT method 1940 
may first prime an EVENT audit trail (if required) by writing 
appropriate information to an EVENT method Audit Trail 
UDE (blocks 1942, 1944). EVENT method 1940 may then 
obtain and load an EVENT method map DTD from the 
secure database (blocks 1946, 1948). This EVENT method 
map DTD describes, in this example, the format of the 
EVENT method map MDE to be read and accessed imme- 
diately subsequently (by blocks 1950, 1952). In the pre- 
ferred embodiment, MDEs and UDEs may have any of 
various different formats, and their formats may be flexibly 
specified or changed dynamically depending upon the 
installation, user, etc. The DTD, in effect, describes to the 
EVENT method 1940 how to read from the EVENT method 
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map MDE. DTDs are also used to specify how methods 
should write to MDEs and UDEs, and thus may be used to 
implement privacy filters by, for example, preventing certain 
confidential user information from being written to data 
structures that will be reported to third parties. 5 

Block 1950 ("map event to atomic element # and event 
count using a Map MDE") is in some sense the "heart" of 
EVENT method 1940. This step "maps" the event into an 
"atomic element number" to be responded to by subse- 
quently called methods. An example of process control steps 10 
performed by a somewhat representative example of this 
"mapping" step 1950 is shown in FIG. 53fc. 

The FIG. 53b example shows the process of converting a 
READ event that is associated with requesting byte range 
1001-1500 from a specific piece of content into an appro- 
priate atomic element. The example EVENT method map- 
ping process (block 1950 in FIG. 53a) can be detailed as the 
representative process shown in FIG. 53b. 

EVENT method mapping process 1950 may first look up 
the event code (READ) in the EVENT method MDE (1952) 
using the EVENT method map DTD (1948) to determine the 20 
structure and contents of the MDE. A test might then be 
performed to determine if the event code was found in the 
MDE (1956), and if not ("No" branch), the EVENT method 
mapping process may the terminate (1958) without mapping 
the event to an atomic element number and count. If the 25 
event was found in the MDE ("Yes" branch), the EVENT 
method mapping process may then compare the event range 
(e.g., bytes 1001-1500) against the atomic element to event 
range mapping table stored in the MDE (block 1960). The 
comparison might yield one or more atomic element num- 30 
bers or the event range might not be found in the mapping 
table. The result of the comparison might then be tested 
(block 1962) to determine if any atomic element numbers 
were found in the table. If not ("No" branch), the EVENT 
method mapping process may terminate without selecting 35 
any atomic element numbers or counts (1964). If the atomic 
element numbers were found, the process might then cal- 
culate the atomic element count from the event range (1966). 
In this example, the process might calculate the number of 
bytes requested by subtracting the upper byte range from the 
lower byte range (e.g., 1500-1001+1-500). The example 40 
EVENT method mapping process might then terminate 
(block 1968) and return the atomic element number(s) and 
counts. 

EVENT method 1940 may then write an EVENT audit 
trail if required to an EVENT method Audit Trail UDE 45 
(block 1970, 1972). EVENT method 1940 may then prepare 
to pass the atomic element number and event count to the 
calling CONTROL method (or other control process) (at exit 
point 1978). Before that, however, EVENT method 1940 
may test whether an atomic element was selected (decision 50 
block 1974). If no atomic element was selected, then the 
EVENT method may be failed (block 1974). This may occur 
for a number of reasons. For example, the EVENT method 
may fail to map an event into an atomic element if the user 
is not authorized to access the specific areas of content that 55 
the EVENT method MDE does not describe. This mecha- 
nism could be used, for example, to distribute customized 
versions of a piece of content and control access to the 
various versions in the content object by altering the EVENT 
method MDE delivered to the user. A specific use of this 60 
technology might be to control the distribution of different 
language (e.g., English, French, Spanish) versions of a piece 
of content. 

Billing 6S 

FIG. 53c is a flowchart of an example of process control 
steps performed by a BILLING method 1980. Examples of 
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BILLING methods are set forth in FIGS. 494 504 and Sid 
and are described above. BILLING method 1980 shown in 
FIG. 53c is somewhat more generalized than the examples 
above. Like the BILLING method examples above, BILL- 
ING method 1980 receives a meter value to determine the 
amount to bill. BILLING method 1980 may first prime a 
BILLING audit trail (if required) by writing appropriate 
information to the BILLING method Audit Trail UDE 
(blocks 1982, 1984). BILLING method 1980 may then 
obtain and load a BILLING method map DTD from the 
secure database (blocks 1985, 1986), which describes the 
BILLING method map MDE (e.g., a price list, table, or 
parameters to the billing amount calculation algorithm) that 
should be used by this BILLING method. The BILLING 
method map MDE may be delivered either as part of the 
content object or as a separately deliverable component that 
is combined with the control information at registration. 

The BILLING method map MDE in this example may 
describe the pricing algorithm that should be used in this 
BILLING method (e.g., bill $0,001 per byte of content 
released). Block 1988 ("Map meter value to billing 
amount") functions in the same manner as block 1950 of the 
EVENT method; it maps the meter value to a billing value. 
Process step 1988 may also interrogate the secure database 
(as limited by the privacy filter) to determine if other objects 
or information (e.g., user information) are present as part of 
the BILLING method algorithm. 

BILLING method 1980 may then write a BILLING audit 
trail if required to a BILLING method Audit Trail UDE 
(block 1990, 1992), and may prepare to return the billing 
amount to the calling CONTROL method (or other control 
process). Before that, however, BILLING method 1980 may 
test whether a billing amount was determined (decision 
block 1994). If no billing amount was determined, then the 
BILLING method may be failed (block 1996). This may 
occur if the user is not authorized to access the specific areas 
of the pricing table that the BILLING method MDE 
describes (e.g., you may purchase not more than $100.00 of 
information from this content object). 

Access 

FIG. 54 is a flowchart of an example of program control 
steps performed by an ACCESS method 2000. As described 
above, an ACCESS method may be used to access content 
embedded in an object 300 so it can be written to, read from, 
or otherwise manipulated or processed. In many cases, the 
ACCESS method may be relatively trivial since the object 
may, for example, be stored in a local storage that is easily 
accessible. However, in the general case, an ACCESS 
method 2000 must go through a more complicated proce- 
dure in order to obtain the object. For example, some objects 
(or parts of objects) may only be available at remote sites or 
may be provided in the form of a real-time download or feed 
(e.g., in the case of broadcast transmissions). Even if the 
object is stored locally to the VDE node, it may be stored as 
a secure or protected object so that it is not directly acces- 
sible to a calling process. ACCESS method 2000 establishes 
the connections, routings, and security requisites needed to 
access the object. These steps may be performed transpar- 
ently to the calling process so that the calling process only 
needs to issue an access request and the particular ACCESS 
method corresponding to the object or class of objects 
handles all of the details and logistics involved in actually 
accessing the object. 

ACCESS method 2000 may first prime an ACCESS audit 
trail (if required) by writing to an ACCESS Audit Trail UDE 
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(blocks 2002, 2004). ACCESS method 2000 may then read ENCRYPT method 2050. ENCRYPT method 2050 is passed 

and load an ACCESS method DTD in order to determine the as an input, a block of information to encrypt (or a pointer 

format of an ACCESS MDE (blocks 2006, 2008). The indicating where it may be found). ENCRYPT method 2050 

ACCESS method MDE specifies the source and routing then may determine an encryption key to use from a key 

information for the particular object to be accessed in the 5 block (block 2052). The encryption key selection makes a 

preferred embodiment. Using the ACCESS method DTD, determination if a key for a specific block of content to be 

ACCESS method 2000 may load the correction parameters written already exists in a key block stored in PERC 808. If 

(e.g., by telephone number, account ID, password and/or a the key already exists in the key block, then the appropriate 

request script in the remote resource dependent language). key number is selected. If no such key exists in the key 

ACCESS method 2000 reads the ACCESS method MDE ™ block, a new key is calculated using an algorithm appropri- 

from the secure database, reads it in accordance with the ate to the encryption algorithm. This key is then stored in the 

ACCESS method DTD, and loads encrypted content source key block of PERC 808 so that DECRYPT method 2030 

and routing information based on the MDE (blocks 2010, may access the key in order to decrypt the content stored in 

2012). This source and routing information specifies the ^ content object. ENCRYPT method 2050 then accesses 

location of the encrypted content. ACCESS method 2000 15 the appropriate PERC to obtain, derive and/or compute an 

then determines whether a connection to the content is encryption key to be used to encrypt the information block 

available (decision block 2014). This "connection" could be, (blocks 2054, 2056, 2058, which are similar to FIG. 55a 

for example, an on-line connection to a remote site, a blocks 2034, 2036, 2038). ENCRYPT method 2050 then 

real-time information feed, or a path to a secure/protected actually encrypts the information block using the obtained 

resource, for example. If the connection to the content is not M and/or derived encryption key (block 2060) and outputs the 

currently available ("No" exit of decision block 2014), then encrypted information block or a pointer where it can be 

ACCESS method 2000 takes steps to open the connection found before terminating (termination point 2062). 
(block 2016). If the connection fails (e.g., because the user 

is not authorized to access a protected secure resource), then Content 

the ACCESS method 2000 returns with a failure indication 25 piG 56 fc a flowchart of an example of process control 

(termination point 2018). If the open connection succeeds, steps per f ormec } by a representative of a CONTENT method 

on the other hand, then ACCESS method 2000 obtains the 2 070 provided by the preferred embodiment. CONTENT 

encrypted content (block 2020). ACCESS method 2000 then mcthod 2 070 in the preferred embodiment builds a "synop- 

writes an ACCESS audit trail if required to the secure sis » of protected conteQt using a secure pr0 cess. For 

database ACCESS method Audit Trail UDE (blocks 2022, 30 examplC) CONTENT method 2070 may be used to derive 

2024), and then terminates (terminate point 2026). unsecure ("public") information from secure content. Such 

Decrypt and Encrypt derived public information might include, for example, an 

FIG. SSa is a flowchart of an example of process control ab f ™ \' an ,, index > f 'f le «f «nto»t^ * directory of files, a 

steps performed by a representative example of a DECRYPT 35 S^"? a '"ovle ™ ™ ™ 

method 2030 provided by the preferred embodiment. or exam P e » a movie er * 

DECRYPT method 2030 in the preferred embodiment CONTENT method 2070 begins by determining whether 
obtains or derives a decryption key from an appropriate the derived content to be provided must be derived from 
PERC 808, and uses it to decrypt a block of encrypted secure contents, or whether it is already available in the 
content. DECRYPT method 2030 is passed a block of 4 o ob i ect in ^ form of static values (decision block 2070). 
encrypted content or a pointer to where the encrypted block Some objects may, for example, contain prestored abstracts, 
is stored. DECRYPT 2030 selects a key number from a key indexes, tables of contents, etc., provided expressly for the 
block (block 2032). For security purposes, a content object purpose of being extracted by the CONTENT method 2070. 
may be encrypted with more than one key. For example, a If tne object contains such static values ("static" exit to 
movie may have the first 10 minutes encrypted using a first 45 decision block 2072), then CONTENT method 2070 may 
key, the second 10 minutes encrypted with a second key, and simply read this static value content information from the 
so on. These keys are stored in a PERC 808 in a structure ob i ect (block 2074), optionally decrypt, and release this 
called a "key block." The selection process involves deter- content description (block 2076). If, on the other hand, 
mining the correct key to use from the key block in order to CONTENT method 2070 must derive the synopsis/content 
decrypt the content. The process for this selection is similar 50 desc ripuon from the secure object ("derived" exit to deed- 
to the process used by EVENT methods to map events into sion block 2072 X ^en the CONTENT method may then 
atomic element numbers. DECRYPT method 2030 may then securely read information from the container according to a 
access an appropriate PERC 808 from the secure database synopsis algorithm to produce the synopsis (block 2078). 
610 and loads a key (or "seed") from a PERC (blocks 2034, 

2036). This key information may be the actual decryption 55 Extract and Embcd 

key to be used to decrypt the content, or it may be infor- FIG. 57a is a flowchart of an example of process control 

mation from which the decryption key may be at least in part steps performed by a representative example of an 

derived or calculated. If necessary, DECRYPT method 2030 EXTRACT method 2080 provided by the preferred embodi- 

computes the decryption key based on the information read ment. EXTRACT method 2080 is used to copy or remove 

from PERC 808 at block 2034 (block 2038). DECRYPT 6 o content from an object and place it into a new object. In the 

method 2030 then uses the obtained and/or calculated preferred embodiment, the EXTRACT method 2080 does 

decryption key to actually decrypt the block of encrypted not involve any release of content, but rather simply takes 

information (block 2040). DECRYPT method 2030 outputs content from one container and places it into another 

the decrypted block (or the pointer indicating where it may container, both of which may be secure. Extraction of 

be found), and terminates (termination point 2042). 6S content differs from release in that the content is never 

FIG. 55b is a flowchart of an example of process control exposed outside a secure container. Extraction and Embed- 

steps performed by a representative example of an ding are complementary functions; extract takes content 
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from a container and creates a new container containing the 
extracted content and any specified control information 
associated with that content. Embedding takes content that 
is already in a container and stores it (or the complete object) 
in another container directly and/or by reference, integrating 5 
the control information associated with existing content with 
those of the new content. 

EXTRACT method 2080 begins by priming an Audit 
UDE (blocks 2082, 2084). EXTRACT method then calls a 
BUDGET method to make sure that the user has enough 10 
budget for (and is authorized to) extract content from the 
original object (block 2086). If the user's budget does not 
permit the extraction ("no" exit to decision block 2088), then 
EXTRACT method 2080 may write a failure audit record 
(block 2090), and terminate (termination point 2092). If the 15 
user's budget permits the extraction ("yes" exit to decision 
block 2088), then the EXTRACT method 2080 creates a 
copy of the extracted object with specified rules and control 
information (block 2094). In the preferred embodiment, this 
step involves calling a method that actually controls the 20 
copy. This step may or may not involve decryption and 
encryption, depending on the particular the PERC 808 
associated with the original object, for example. EXTRACT 
method 2080 then checks whether any control changes are 
permitted by the rights authorizing the extract to begin with 25 
(decision block 2096). In some cases, the extract rights 
require an exact copy of the PERC 808 associated with the 
original object (or a PERC included for this purpose) to be 
placed in the new (destination) container ("no" exit to 
decision block 2096). If no control changes are permitted, 30 
then extract method 2080 may simply write audit informa- 
tion to the Audit UDE (blocks 2098, 2100) before terminat- 
ing (terminate point 2102). If, on the other hand, the extract 
rights permit the user to make control changes ("yes" to 
decision block 2096), then EXTRACT method 2080 may 3s 
call a method or load module that solicits new or changed 
control information (e.g., from the user, the distributor who 
created/granted extract rights, or from some other source) 
from the user (blocks 2104, 2106). EXTRACT method 2080 
may then call a method or load module to create a new 40 
PERC that reflects these user-specified control information 
(block 2104). This new PERC is then placed in the new 
(destination) object, the auditing steps are performed, and 
the process terminates. 

FIG. 57 b is an example of process control steps performed 45 
by a representative example of an EMBED method 2110 
provided by the preferred embodiment. EMBED method 
2110 is similar to EXTRACT method 2080 shown in FIG. 
57a. However, the EMBED method 2110 performs a slightly 
different function — it writes an object (or reference) into a 50 
destination container. Blocks 2112-2122 shown in FIG. Sib 
are similar to blocks 2082-2092 shown in FIG. 57a. At 
block 2124, EMBED method 2110 writes the source object 
into the destination container, and may at the same time 
extract or change the control information of the destination 55 
container. One alternative is to simply leave the control 
information of the destination container alone, and include 
the full set of control information associated with the object 
being embedded in addition to the original container control 
information. As an optimization, however, the preferred 60 
embodiment provides a technique whereby the control infor- 
mation associated with the object being embedded are 
"abstracted" and incorporated into the control information of 
the destination container, Block 2124 may call a method to 
abstract or change this control information. EMBED method 65 
2110 then performs steps 2126-2130 which are similar to 
steps 2096, 2104, 2106 shown in FIG. 57a to allow the user, 



if authorized, to change and/or specify control information 
associated with the embedded object and/or destination 
container. EMBED method 2110 then writes audit informa- 
tion into an Audit UDE (blocks 2132, 2134), before termi- 
nating (at termination point 2136). 

Obscure 

FIG. 58a is a flowchart of an example of process control 
steps performed by a representative example of an 
OBSCURE method 2140 provided by the preferred embodi- 
ment. OBSCURE method 2140 is typically used to release 
secure content in devalued form. For example, OBSCURE 
method 2140 may release a high resolution image in a lower 
resolution so that a viewer can appreciate the image but not 
enjoy its full value. As another example, the OBSCURE 
method 2140 may place an obscuring legend (e.g., "COPY," 
"PROOF," etc.) across an image to devalue it. OBSCURE 
method 2140 may "obscure" text, images, audio 
information, or any other type of content. 

OBSCURE method 2140 first calls an EVENT method to 
determine if the content is appropriate and in the range to be 
obscured (block 2142). If the content is not appropriate for 
obscuring, the OBSCURE method terminates (decision 
block 2144 "no" exit, terminate point 2146). Assuming that 
the content is to be obscured ("yes" exit to decision block 
2144), then OBSCURE method 2140 determines whether it 
has previously been called to obscure this content (decision 
block 2148). Assuming the OBSCURE 2140 has not previ- 
ously called for this object/content ("yes" exit to decision 
block 2148), the OBSCURE method 2140 reads an appro- 
priate OBSCURE method MDE from the secure database 
and loads an obscure formula and/or pattern from the MDE 
(blocks 2150, 2152). The OBSCURE method 2140 may then 
apply the appropriate obscure transform based on the patters 
and/or formulas loaded by block 2150 (block 2154). The 
OBSCURE method then may terminate (terminate block 
2156). 

Fingerprint 

FIG. 58b is a flowchart of an example of process control 
steps performed by a representative example of a FINGER- 
PRINT method 2160 provided by the preferred embodiment. 
FINGERPRINT method 2160 in the preferred embodiment 
operates to "mark" released content with a "fingerprint" 
identification of who released the content and/or check for 
such marks. This allows one to later determine who released 
unsecured content by examining the content. FINGER- 
PRINT method 2160 may, for example, insert a user ID 
within a datastream representing audio, video, or binary 
format information. FINGERPRINT method 2160 is quite 
similar to OBSCURE method 2140 shown in FIG. 58a 
except that the transform applied by FINGERPRINT 
method block 2174 "fingerprints" the released content rather 
than obscuring it. 

FIG. 58c shows an example of a "fingerprinting" proce- 
dure 2160 that inserts into released content "fingerprints" 
2161 that identify the object and/or property and/or the user 
that requested the released content and/or the date and time 
of the release and/or other identification criteria of the 
released content. 

Such fingerprints 2161 can be "buried" — that is inserted 
in a manner that hides the fingerprints from typical users, 
sophisticated "hackers," and/or from all users, depending on 
the file format, the sophistication and/or variety of the 
insertion algorithms, and on the availability of original, 
non-fingerprinted content (for comparison for reverse engi- 
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neering of algorithm(s)). Inserted or embedded fingerprints one or more binary "on or off" bits for digital information 

2161, in a preferred embodiment, may be at least in part storage. The N pixels might be either consistent, or 

encrypted to make them more secure. Such encrypted fin- alternatively, pseudo-random in order (but interpretable, at 

gcrprints 2161 may be embedded within released content least in part, by a object creator, object provider, client 

provided in "clear" (plaintext) form. 5 administrator, and/or VDE administrator). 

Fingerprints 2161 can be used for a variety of purposes Other modifications of an image (or moving image, audio, 

including, for example, the often related purposes of proving ctc ;> whlch W™*? * simil t ar benc * 1 f>™S 

misuse of released materials and proving the source of m f atloa "\ a form * a * n ° f l ° 0rmaUy °T r ^ * 

, j 4 4 0 - . \ * i j of a certain modification of the source information) may be 

released content. Software piracy is a particularly good . . , t . - r> i 

. , - • *. « r tiT- m appropriate, depending on the application. For example. 

example where fingerprinting can be very useful. Finger- 10 r \ . r , ' r 7. • t . r c * j j* 

. A . r . , f / r 0 4 , . . , A °- certain subtle modifications in the frequency 01 stored audio 

printing can also help to enforce content providers rights for . r . , 4 7 „ 

r w & r 1 * ■ 11 j i- j *c • 1 j- information can be modified so as to be normally unnotice- 

most types of electronically delivered information including 11 . it _ 1- . 1.1 ^« 1. • j li 

. Jr ,. J l4 . . - i . & able to the listener while still being readable with the proper 

movies, audio recordings, multimedia, information . . ^ . . .. ... . & - . - . 

, 4 . j j j *j * 1 ,m- » • * tools. Certam properties of the storage of information might 

databases, and traditional literary materials. Fingerprint- , jcj. -j l r 1.* u * • « *ui • 

j . . , ^ 4 . , * *• k be modified to provide such slight but interpretable vana- 

mg is a desirable alternative or addition to copy protection. 15 4 . . , - 4 * *•■*** i_- • *• u 

0 rj r tions ui polarity of certam information which is optically 

Most piracy of software applications, for example, occurs stored to acme ve sin j i]ar iesultSt other variations employing 

not with the making of an illicit copy by an individual for use other electronic, magnetic, and/or optical characteristic may 

on another of the individual's own computers, but rather in ^ e employed 

giving a copy to another party This often starts a chain (or Content stored ^ files ^ j graphical formats, 

more accurately a pyramid) of illegid copies, as copies are such ^ Microsof , windows word pr0C essing files, provide 

handed from individual to individual. The fear of identifi- sj mcant opportuniti6S for "burying" a fingerprint 2161. 

catwn resulting from the embedding of a fingerprint 2161 that jncludes ^ and/or ^ ides the 

win likely chssuade most indmduab from participating, as rtunit t0 embed nngerprints 2 161 that may be difficult 

many currently do, in widespread, "casual piracy In some for uoaumorired individuals to identify since, in the absence 

cases, content may be checked for the presence of a finger- of aQ << UDfingerprinted .. original for purposes of comparison, 

print by a fingerprint method to help enforce content pro- mjnor sMe variations at one or more ^ instances m 

v ers ngnis. audio frequencies, or in one or more video images, or the 

Different fingerprints 2161 can have different levels of w iUbe in themselves undiscernible given the normally 

security (e.g., one fingerprint 2161(1) could be readable/ 3Q unknown nature of the original and the large amounts of data 

identifiable by commercial concerns, while another finger- employed in both image and sound data (and which is not 

print 2161(2) could be readable only by a more trusted particularly sensitive to minor variations). With formatted 

agency. The methods for generating the more secure finger- text documents, particularly those created with graphical 

print 2161 might employ more complex encryption tech- word processors (such as Microsoft Windows or Apple 

niques (e.g., digital signatures) and/or obscuring of location 35 Macintosh word processors and their DOS and Unix 

methodologies. Two or more fingerprints 2161 can be equivalents), fingerprints 2161 can normally be inserted 

embedded in different locations and/or using different tech- unobtrusively into portions of the document data represen- 

niques to help protect fingerprinted information against tation that are not non naUy visible to the end user (such as 

hackers. The more secure fingerprints might only be in a beader or other aon -displayed data field), 

employed periodically rather than each time content release 4Q Yet mofhtT form of fingcrprin ting, which may be particu- 

occurs, if the technique used to provide a more secure M suitable for UxtuaJ would , 

fingerprint involves an undesired amount of additional over- and mnM mc formation of characters for a given font, 

head. Tins may nevertheless be effective since a principal Individual characters may have a slightly different visual 

objective of fingerpnntmg is deterrence-that is the fear on formation which certain "fingerprint" information, 

the part of the creator of an illicit copy that the copying will 45 nis alteralion of a gi vea character's form would be gener- 

out ' ally undiscernible, in part because so many slight variations 

For example, one might embed a copy of a fingerprint ex i st j n versions of the same font available from different 
2161 which might be readily identified by an authorized suppliers, and in part because of the smaUness of the 
party— for example a distributor, service personal, client variation. For example, in a preferred embodiment, a pro- 
administrator, or clearinghouse using a VDE electronic 50 grarn sucn as Adobe Type Align could be used which, in its 
appliance 600. One might embed one or more additional off-the-shelf versions, supports the ability of a user to 
copies or variants of a fingerprint 2161 (e.g., fingerprints modify font characters in a variety of ways. The mathemati- 
carrying information describing some or all relevant iden- ca i definition of the font character is modified according to 
tifying information) and this additional one or more finger- the user's instructions to produce a specific set of modifi- 
prints 2161 might be maintained in a more secure manner. 55 cations to be applied to a character or font. Information 

Fingerprinting can also protect privacy concerns. For content could be used in an analogous manner (as an 

example, the algorithm and/or mechanisms needed to iden- alternative to user selections) to modify certain or all char- 

tify the fingerprint 2161 might be available only through a acters too subtly for user recognition under normal circum- 

particularly trusted agent. stances but which nevertheless provide appropriate encod- 

Fingerprinting 2161 can take many forms. For example, 60 ing for the fingerprint 2161. Various subtly different versions 

in an image, the color of every N pixels (spread across an of a given character might be used within a single document 

image, or spread across a subset of the image) might be so as to increase the ability to carry transaction related font 

subtly shifted in a visually unnoticeable manner (at least fingerprinted information. 

according to the normal, unaided observer). These shifts Some other examples of applications for fingerprinting 

could be interpreted by analysis of the image (with or 65 might include: 

without access to the original image), with each occurrence 1. In software programs, selecting certain interchangeable 

or lack of occurrence of a shift in color (or greyscale) being code fragments in such a way as to produce more or less 
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identical operation, but on analysis, differences that detail example. In the preferred embodiment, METER method 

fingerprint information. 2220 first primes an Audit Trail by accessing a METER 

2. With databases, selecting to format certain fields, such as Audit Trail UDE (blocks 2222, 2224). METER method 2220 
dates, to appear in different ways. may then read the DTD for the Meter UDE from the secure 

3. In games, adjusting backgrounds, or changing order of 5 database (blocks 2226, 2228). METER method 2220 may 
certain events, including noticeable or very subtle then read the Meter UDE from the secure database (blocks 
changes in timing and/or ordering of appearance of game 2230, 2232). METER method 2220 next may test the 
elements, or slight changes in the look of elements of the obtained Meter UDE to determine whether it has expired 
game. (decision block 2234). In the preferred embodiment, each 
Fingerprinting method 2160 is typically performed (if at 10 Meter UDE may be marked with an expiration date. If the 

all) at the point at which content is released from a content current date/time is later than the expiration date of the 

object 300. However, it could also be performed upon Meter UDE ("yes" exit to decision block 2234), then the 

distribution of an object to "mark" the content while still in METER method 2220 may record a failure in the Audit 

encrypted form. For example, a network-based object Record and terminate with a failure condition (block 2236, 

repository could embed fingerprints 2161 into the content of 15 2238). 

an object before transmitting the object to the requester, the Assuming the Meter UDE is not yet expired, the meter 

fingerprint information could identify a content requester/ method 2220 may update it using the atomic element and 

end user. This could help detect "spoof electronic appli- CVCQ t count passed to the METER method from, for 

ances 600 used to release content without authorization. example, an EVENT method (blocks 2239, 2240). The 

20 METER method 2220 may then save the Meter Use Audit 

Uestroy Record in the Meter Audit Trail UDE (blocks 2242, 2244), 

FIG. 59 is a flowchart of an example of process control before terminating (at terminate point 2246). 
steps performed by a representative performed by a 

DESTROY method 2180 provided by the preferred embodi- Additional Security Features Provided by the 

ment. DESTROY method 2180 removes the ability of a user 25 Preferred Embodiment 

to use an object by destroying the URT the user requires to ^ m ^ b lhe preferred embodiment has 

™o™ ° h l^ ™ thC ? referred embodiment, a sufficient sccurit to hcl eQSUre that [{ cannot be CQ 

DESTOOYme^ to mised short of a successfill « brute force attack » md so mat 

an Audit UDE (b locks 2182, 2184). DESTROY method me ^ and ^ to succced ^ such a ^ mte ' forcc attacr 

2180 may than call a WRITE and/or ACCESS method to 30 su5stantiall exceeds value to be derived< In addltion , 

write information which will corrupt (and thus destroy) the ±t securit Med b TO 100 compartmcntalizes tne 

^t^e™i er 7 V ^ll PartS u° f th& ? JeCt (bl ° Ck eternal workings of VDE so that a successful "brute force 

2186). DESTROY method 2180 may then mark one or more attacr WQuld only a stricdy bounded subset of 

of the control structures (e.g., the URTO as damaged by tected mformatiori) not the entire system . 

writing appropriate information to the control structure ™ * tI . . 

(blocks 2188, 2190). DESTROY method 2180, finally, may ^ foUowing are among security aspects and features 

write additional audit information to Audit UDE (blocks P r0Vlded b ? the P referred embodiment: 

2192, 2194) before terminating (terminate point 2196). security of PPE 650 and the processes it performs 

security of secure database 610 

security of encryption/decryption performed by PPE 650 

FIG, 60 is a flowchart of an example of process control key management; security of encryption/decryption keys 

steps performed by a representative example of a PANIC and shared secrets 

method 2200 provided by the preferred embodiment. PANIC security of authentication/external communications 

method I 220C I may be called I when a security violation is 45 seajrit of badm 

detected. PANIC method 2200 may prevent the user from „ 

further accessing the object currently being accessed by, for secure transportability of VDE internal information 

example, destroying the channel being used to access the between electronic appliances 600 

object and marking one or more of the control structures security of permissions to access VDE secure information 

(e.g., the URT) associated with the user and object as 50 security of VDE objects 300 

damaged (blocks 2206, and 2208-2210, respectively). integrity of VDE security. 

Because the control structure is damaged, the VDE node will Some of these security aspects and considerations are 

need to contact an administrator to obtain a valid control discussed above. The foUowing provides an expanded dis- 

structure(s) before the user may access the same object cussion of preferred embodiment security features not fully 

again. When the VDE node contacts the administrator, the 5S addressed elsewhere, 
administrator may request information sufficient to satisfy 

itself that no security violation occurred, or if a security Management of Keys and Shared Secrets 

violation did occur, take appropriate steps to ensure that the , mr , , , 

security violation is not repeated. VDE 100 uses ke ? s and shared secrets to P r0Vlde security. 

The following key usage features are provided by the 

Meter 60 preferred embodiment: 

FIG. 61 is a flowchart of an example of process control different cryptosystem/key types 

steps performed by a representative example of a METER secure key length 

method provided by the preferred embodiment. Although key generation 

METER methods were described above in connection with 65 key "convolution" and key "aging." 

FIGS. 49, 50 and 51, the METER method 2220 shown in Each of these types are discussed below. 

FIG. 61 is possibly a somewhat more representative A. Public- Key and Symmetric Key Cryptosystems 
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The process of disguising or transforming information to systems for communications may provide advantages such 

hide its substance is called encryption. Encryption produces as eliminating reliance on secret shared external communi- 

"ciphertext." Reversing the encryption process to recover cation keys to establish communications, allowing for a 

the substance from the ciphertext is called "decryption." A challenge/response that doesn't rely on shared internal 

cryptographic algorithm is the mathematical function used 5 secrets to authenticate PPEs 650, and allowing for a publicly 

for encryption and decryption. available "certification" process without reliance on shared 

Most modern cryptographic algorithms use a "key." The secret keys, 

"key" specifies one of a family of transformations to be Some content providers may wish to restrict use of their 

provided. Keys allow a standard, published and tested content to PK implementations. This desire can be supported 

cryptographic algorithm to be used while ensuring that 10 by making the availability of PK capabilities, and the 

specific transformations performed using the algorithm are specific nature or type of PK capabilities, in PPEs 650 a 

kept secret. The secrecy of the particular transformations f actor in the registration of VDE objects 300, for example, 

thus depends on the secrecy of the key, not on the secrecy by including a requirement in a REGISTER method for such 

of the algorithm. objects in the form of a load module that examines a PPE 

There are two general forms of key-based algorithms, 15 650 for specific or general PK capabilities before allowing 

either or both of which may be used by the preferred registration to continue. 

embodiment PPE 650: Although VDE 100 does not require any specific 

symmetric; and algorithm, it is highly desirable that all PPEs 650 are capable 

public-key ("PK"). of using the same algorithm for bulk encryption/decryption. 

Symmetric algorithms are algorithms where the encryp- 20 If the bulk encryption/decryption algorithm used for 

tion key can be calculated from the decryption key and vice encrypting VDE objects 300 is not standardized, then it is 

versa. In many such systems, the encryption and decryption possible that not all VDE electronic appliances 600 will be 

keys are the same. The algorithms, also called "secret-key", capable of handling all VDE objects 300. Performance 

"single key" or "shared secret" algorithms, require a sender differences will exist between different PPEs 650 and asso- 

and receiver to agree on a key before ciphertext produced by 25 ciated electronic appliances 600 if standardized bulk 

a sender can be decrypted by a receiver. This key must be encryption/decryption algorithms are not implemented in 

kept secret. The security of a symmetric algorithm rests in whole or in part by hardware-based encrypt/decrypt engine 

the key: divulging the key means that anybody could encrypt 522, and instead are implemented in software. In order to 

and decrypt information in such a cryptosystem. See support algorithms that are not implemented in whole or in 

Schuster, Applied Cryptography at Page 3. Some examples 30 part by encrypt/decrypt engine 522, a component assembly 

of symmetric key algorithms that the preferred embodiment that implements such an algorithm must be available to a 

may use include DES, Skipjack/Clipper, IDEA, RC2, and PPE 650. 

RC4. B. Key Length 

In public-key cryptosystems, the key used for encryption Increased key length may increase security. A "brute - 
is different from the key used for decryption. Furthermore, 35 force" attack of a cryptosystem involves trying every pos- 
it is computationally infeasible to derive one key from the sible key. The longer the key, the more possible keys there 
other. The algorithms used in these cryptosystems are called are to try. At some key length, available computation 
"public key" because one of the two keys can be made resources will require an unpractically large amount of time 
public without endangering the security of the other key. for a "brute force" attacker to try every possible key. 
They are also sometimes called "asymmetric" cryptosys- 40 VDE 100 provided by the preferred embodiment accom- 
tems because they use different keys for encryption and modates and can use many different key lengths. The length 
decryption. Examples of public-key algorithms include of keys used by VDE 100 in the preferred embodiment is 
RSA, El Gamal and LUC. determined by the algorithm(s) used for encryption/ 
The preferred embodiment PPE 650 may operate based on decryption, the level of security desired, and throughput 
only symmetric key cryptosystems, based on public-key 45 requirements. Longer keys generally require additional pro- 
cryptosystems, or based on both symmetric key cryptosys- cessing power to ensure fast encryption/decryption response 
tems and public-key cryptosystems. VDE 100 does not times. Therefore, there is a tradeoff between (a) security, and 
require any specific encryption algorithms; the architecture (b) processing time and/or resources. Since a hardware - 
provided by the preferred embodiment may support numer- based PPE encrypt/decrypt engine 522 may provide faster 
ous algorithms including PK and/or secret key (non PK) 50 processing than software-based encryption/decryption, the 
algorithms. In some cases, the choice of encryption/ hardware-based approach may, in general, allow use of 
decryption algorithm will be dependent on a number of longer keys. 

business decisions such as cost, market demands, compat- The preferred embodiment may use a 1024 bit modulus 

ibility with other commercially available systems, export (key) RSA cryptosystem implementation for PK encryption/ 

laws, etc. 55 decryption, and may use 56-bit DES for "bulk" encryption/ 

Although the preferred embodiment is not dependent on decryption. Since the 56-bit key provided by standard DES 

any particular type of cryptosystem or encryption/ may not be long enough to provide sufficient security for at 

decryption algorithm(s), the preferred example uses PK least the most sensitive VDE information, multiple DES 

cryptosystems for secure communications between PPEs encryptions using multiple passes and multiple DES keys 

650, and uses secret key cryptosystems for "bulk" 60 may be used to provide additional security. DES can be 

encryption/decryption of VDE objects 300. Using secret key made significantly more secure if operated in a manner that 

cryptosystems (e.g., DES implementations using multiple uses multiple passes with different keys. For example, three 

keys and multiple passes, Skipjack, RC2, or RC4) for "bulk" passes with 2 or 3 separate keys is much more secure 

encryption/decryption provides efficiencies in encrypting because it effectively increases the length of the key. RC2 

and decrypting large quantities of information, and also 65 and RC4 (alternatives to DES) can be exported for up to 

permits PPEs 650 without PK-capability to deal with VDE 40-bit key sizes, but the key size probably needs to be much 

objects 300 in a variety of applications. Using PK crypto- greater to provide even DES level security. The 80-bit key 
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length provided by NSA's Skipjack may be adequate for rithm (e.g., DES in Output Feedback Mode) to generate a 

most VDE security needs. sequence of pseudo-random values derived from a secret 

The capability of downloading code and other infonna- value protected within the SPE. Although these numbers are 

tion dynamically into PPE 650 allows key length to be pseudo-random rather than truly random, they are crypto- 

adjusted and changed dynamically even after a significant 5 graphically derived from a value unknown outside the SPE 

number of VDE electronic appliances 600 are in use. The 503 and therefore may be satisfactory in some applications, 

ability of a VDE administrator to communicate with each In an embodiment incorporating an HPE 655 without an 

PPE 650 efficiently makes such after-the-fact dynamic SPE 503, the random value generator 565 software may 

changes both possible and cost-effective. New or modified derive reliably random numbers from unpredictable external 

cryptosystems can be downloaded into existing PPEs 650 to 10 physical events (e.g., high-resolution timing of disk I/O 

replace or add to the cryptosystem repertoire available completions or of user keystrokes at an attached keyboard 

within the PPE, allowing older PPEs to maintain compat- 612). 

ibility with newer PPEs and/or newly released VDE objects Conventional techniques for generating PK and non-PK 
300 and other VDE-protected information. For example, keys based upon such "seeds" may be used. Thus, if per- 
software encryption/decryption algorithms may be down- 15 formance and manufacturing costs permit, PPE 650 in the 
loaded into PPE 650 at any time to supplement the preferred embodiment will generate its own public/private 
hardware-based functionality of encrypt/decrypt engine 522 key pair based on such random or pseudo -random "seed" 
by providing different key length capabilities. To provide values. This key pair may then be used for external corn- 
increased flexibility, PPE encrypt/decrypt engine 522 may munications between the PPE 650 that generated the key 
be configured to anticipate multiple passes and/or variable 20 pair and other PPEs that wish to communicate with it. For 
and/or longer key lengths. In addition, it may be desirable to example, the generating PPE 650 may reveal the public key 
provide PPEs 650 with the capability to internally generate of the key pair to other PPEs. This allows other PPEs 650 
longer PK keys. using the public key to encrypt messages that may be 
C. Key Generation decrypted only by the generating PPE (the generating PPE 

Key generation techniques provided by the preferred 25 is the only PPE that "knows" the corresponding "private 

embodiment permit PPE 650 to generate keys and other key"). Similarly, the generating PPE 650 may encrypt mes- 

information that are "known" only to it. sages using its private key that, when decrypted successfully 

The security of encrypted information rests in the security by other PPEs with the generating PPE's public key, permit 

of the key used to encrypt it. If a cryptographically weak the other PPEs to authenticate that the generating PPE sent 

process is used to generate keys, the entire security is weak. 30 the message. 

Good keys are random bit strings so that every possible key Before one PPE 650 uses a public key generated by 

in the key space is equally likely. Therefore, keys should in another PPE, a public key certification process should be 

general be derived from a reliably random source, for used to provide authenticity certificates for the public key. A 

example, by a cryptographically secure pseudo-random public-key certificate is someone's public key "signed" by a 

number generator seeded from such a source. Examples of 35 trustworthy entity such as an authentic PPE 650 or a VDE 

such key generators are described in Schneier, Applied administrator. Certificates are used to thwart attempts to 

Cryptography (John Wiley and Sons, 1994), chapter 15. If convince a PPE 650 that it is communicating with an 

keys are generated outside a given PPE 650 (e.g., by another authentic PPE when it is not (e.g., it is actually communi- 

PPE 650), they must be verified to ensure they come from eating with a person attempting to break the security of PPE 

a trusted source before they can be used. "Certification" may 40 650). One or more VDE administrators in the preferred 

be used to verify keys. embodiment may constitute a certifying authority. By "sign- 

The preferred embodiment PPE 650 provides for the ing" both the public key generated by a PPE 650 and 

automatic generation of keys. For example, the preferred information about the PPE and/or the corresponding VDE 

embodiment PPE 650 may generate its own public/private electronic appliance 600 (e.g., site ID, user ID, expiration 

key pair for use in protecting PK-based external communi- 45 date, name, address, etc.), the VDE administrator certifying 

cations and for other reasons, A PPE 650 may also generate authority can certify that information about the PPE and/or 

its own symmetric keys for various purposes during and the VDE electronic appliance is correct and that the public 

after initialization. Because a PPE 650 provides a secure key belongs to that particular VDE mode, 

environment, most key generation in the preferred embodi- Certificates play an important role in the trustedness of 

ment may occur within the PPE (with the possible exception 50 digital signatures, and also are important in the public-key 

of initial PPE keys used at manufacturing or installation time authentication communications protocol (to be discussed 

to allow a PPE to authenticate initial download messages to below). In the preferred embodiment, these certificates may 

it). include information about the trustedness/level of security of 

Good key generation relies on randomness. The preferred a particular VDE electronic appliance 600 (e.g., whether or 
embodiment PPE 650 may, as mentioned above in connec- 55 not it has a hardware-based SPE 503 or is instead a less 
tion with FIG. 9, includes a hardware-based random number trusted software emulation type HPE 655) that can be used 
generator 542 with the characteristics required to generate to avoid transmitting certain highly secure information to 
reliable random numbers. These random numbers may be less trusted/secure VDE installations, 
used to "seed" a cryptographically strong pseudo -random Certificates can also play an important role in decommis- 
number generator (e.g., DES operated in Output Feedback 60 sioning rogue users and/or sites. By including a site and/or 
Mode) for generation of additional key values derived from user ID in a certificate, a PPE can evaluate this information 
the random seed. In the preferred embodiment, random as an aspect of authentication. For example, if a VDE 
number generator 542 may consist of a "noise diode" or administrator or clearinghouse encounters a certificate bear- 
other physically-based source of random values (e.g., radio- ing an ID (or other information) that meets certain criteria 
active decay). 65 (e.g., is present on a list of decommissioned and/or other- 

If no random number generator 542 is available in the wise suspicious users and/or sites), they may choose to take 

PPE 650, the SPE 503 may employ a cryptographic algo- actions based on those criteria such as refusing to 



03/04/2003, EAST Version: 1.03.0002 



5,892,900 



211 



212 



communicate, communicating disabling information, noti- 
fying the user of the condition, etc. Certificates also typically 
include an expiration date to ensure that certificates must be 
replaced periodically, for example, to ensure that sites and/or 
users must stay in contact with a VDE administrator and/or 5 
to allow certification keys to be changed periodically. More 
than one certificate based on different keys may be issued for 
sites and/or users so that if a given certification key is 
compromised, one or more "backup" certificates may be 
used. If a certification key is compromised, A VDE admin- 10 
istrator may refuse to authenticate based on certificates 
generated with such a key, and send a signal after authen- 
ticating with a "backup" certificate that invalidates all use of 
the compromised key and all certificates associated with it in 
further interactions with VDE participants. A new one or 15 
more "backup" certificates and keys may be created and sent 
to the authenticated site/user after such a compromise. 

If multiple certificates are available, some of the certifi- 
cates may be reserved as backups. Alternatively or in 
addition, one certificate from a group of certificates may be 20 
selected (e.g., by using RNG 542) in a given authentication, 
thereby reducing the likelihood that a certificate associated 
with a compromised certification key will be used. Still 
alternatively, more than one certificate may be used in a 
given authentication. 25 

To guard against the possibility of compromise of the 
certification algorithm (e.g., by an unpredictable advance in 
the mathematical foundations on which the algorithm is 
based), distinct algorithms may used for different certificates 
that are based on different mathematical foundations. 30 

Another technique that may be employed to decrease the 
probability of compromise is to keep secret (in protected 
storage in the PPE 650) the "public" values on which the 
certificates are based, thereby denying an attacker access to 
values that may aid in the attack. Although these values are 35 
nominally "public/' they need be known only to those 
components which actually validate certificates (i.e., the 
PPE 650). 

In the preferred embodiment, PPE 650 may generate its 
own certificate, or the certificate may be obtained externally, 40 
such as from a certifying authority VDE administrator. 
Irrespective of where the digital certificate is generated, the 
certificate is eventually registered by the VDE administrator 
certifying authority so that other VDE electronic appliances 
600 may have access to (and trust) the public key. For 45 
example, PPE 650 may communicate its public key and 
other information to a certifying authority which may then 
encrypt the public key and other information using the 
certifying authority's private key. Other installations 600 
may trust the "certificate" because it can be authenticated by 50 
using the certifying authority's public key to decrypt it. As 
another example, the certifying authority may encrypt the 
public key it receives from the generating PPE 650 and use 
it to encrypt the certifying authority's private key. The 
certifying authority may then send this encrypted informa- 55 
tion back to the generating PPE 650. The generating PPE 
650 may then use the certifying authority's private key to 
internally create a digital certificate, after which it may 
destroy its copy of the certifying authority's private key. The 
generating PPE 650 may then send out its digital certificate 60 
to be stored in a certification repository at the VDE admin- 
istrator (or elsewhere) if desired. The certificate process can 
also be implemented with an external key pair generator and 
certificate generator, but might be somewhat less secure 
depending on the nature of the secure facility. In such a case, 65 
a manufacturing key should be used in PPE 650 to limit 
exposure to the other keys involved. 



A PPE 650 may need more than one certificate. For 
example, a certificate may be needed to assure other users 
that a PPE is authentic, and to identify the PPE. Further 
certificates may be needed for individual users of a PPE 650. 
These certificates may incorporate both user and site infor- 
mation or may only include user information. Generally, a 
certifying authority will require a valid site certificate to be 
presented prior to creating a certificate for a given user. 
Users may each require their own public key/private key 
pair in order to obtain certificates. VDE administrators, 
clearinghouses, and other participants may normally require 
authentication of both the site (PPE 650) and of the user in 
a communication or other interaction. The processes 
described above for key generation and certification for 
PPEs 650 may also be used to form site/user certificates or 
user certificates. 

Certificates as described above may also be used to certify 
the origin of load modules 1100 and/or the authenticity of 
administrative operations. The security and assurance tech- 
niques described above may be employed to decrease the 
probability of compromise for any such certificate 
(including certificates other than the certificate for a VDE 
electronic appliance 600's identity). 
D. Key Aging and Convolution 

PPE 650 also has the ability in the preferred embodiment 
to generate secret keys and other information that is shared 
between multiple PPEs 650. In the preferred embodiment, 
such secret keys and other information may be shared 
between multiple VDE electronic appliances 600 without 
requiring the shared secret information to ever be commu- 
nicated explicitly between the electronic appliances. More 
specifically, PPE 650 uses a technique called "key convo- 
lution" to derive keys based on a deterministic process in 
response to seed information shared between multiple VDE 
electronic appliances 600. Since the multiple electronic 
appliances 600 "know" what the "seed" information is and 
also "know" the deterministic process used to generate keys 
based on this information, each of the electronic appliances 
may independently generate the "true key." This permits 
multiple VDE electronic appliances 600 to share a common 
secret key without potentially compromising its security by 
communicating it over an insecure channel. 

No encryption key should be used for an indefinite period. 
The longer a key is used, the greater the chance that it may 
be compromised and the greater the potential loss if the key 
is compromised but still in use to protect new information. 
The longer a key is used, the more information it may protect 
and therefore the greater the potential rewards for someone 
to spend the effort necessary to break it. Further, if a key is 
used for a long time, there may be more ciphertext available 
to an attacker attempting to break the key using a ciphertext- 
based attack. See Schneier at 150-151. Key convolution in 
the preferred embodiment provides a way to efficiently 
change keys stored in secure database 610 on a routine 
periodic or other basis while simplifying key management 
issues surrounding the change of keys. In addition, key 
convolution may be used to provide "time aged keys" 
(discussed below) to provide "expiration dates" for key 
usage and/or validity. 

FIG. 62 shows an example implementation of key con- 
volution in the preferred embodiment. Key convolution may 
be performed using a combination of a site ID 2821 and the 
high-order bits of the RTC 528 to yield a site-unique value 
"V" that is time-dependent on a large scale (e.g., hours or 
days). This value "V" may be used as the key for an 
encryption process 2871 that transforms a convolution seed 
value 2861 into a "current convolution key" 2862. The seed 
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value 2861 may be a universe-wide or group-wide shared on current real time, other keys might be generated on site 

secret value, and may be stored in secure key storage (e.g., ID, and still other keys might be* generated based on both 

protected memory within PPE 650). The seed value 2861 is current real-time and site ID. 

installed during the manufacturing process and may be Key convolution can be used to provide "time-aged" 

updated occasionally by a VDE administrator. There may be 5 keys. Such "time -aged" keys provide an automatic mecha- 

a plurality of seed values 2861 corresponding to different nism for lowing keys to expire and be replaced by "new" 

sets of objects 300. keys. They provide a way to give a user time-limited rights 

™e current [convolution key 2862 represents an encoding to make ^.^ted use of an object, or portions of an 

of the site ID 2821 and current time. This transformed value object f ^ ^ re . registration bul ret aining 

2862 may be used as a key for anoUner encryption process si m mc hands of thc coment ^ or 

2872 to transform the stored key 810 in the object's PERC J • ■* » tr j*u « n ■ «: ■ *i 

808 into the true private body key 2863 for the object's admimstrator f secure database 610 is sufficienUy secure, 

contents similar capabilities can be accomplished by checking an 

Hie "convolution function" performed by blocks 2861, expiration date/time associated with a key, but this requires 

2871 may, for example, be a one-way function that can be usin S more stora S e s P ace for each ke ? or S 10 ^ of kevs * 

performed independently at both the content creator's site 15 In the preferred embodiment, PERCs 808 can include an 

and at the content user's site. If the content user does not use expiration date and/or time after which access to the VDE- 

precisely the same convolution function and precisely the protected information they correspond to is no longer autho- 

same input values (e.g., time and/or site and/or other rized. Alternatively or in addition, after a duration of time 

information) as used by the content creator, then the result related to some aspect of the use of the electronic appliance 

of the convolution function performed by the content user 20 600 or one or more VDE objects 300, a PERC 808 can force 

will be different from the content creator's result. If the a user to send audit history information to a clearinghouse, 

result is used as a symmetrical key for encryption by the distributor, client administrator, or object creator in order to 

content creator, the content user will not be able to decrypt regain or retain the right to use the object(s). The PERC 808 

unless me content user's result is me same as the result of the can enforce such time-based restrictions by checking/ 

content creator. 25 enforcing parameters that limit key usage and/or availability 

The time component for input to the key convolution past time of authorized use. "Time aged" keys may be used 

function may be derived from RTC 528 (care being taken to to enforce or enhance this type of time-related control of 

ensure that slight differences in RTC synchronization access to VDE protected information. "Time aged" keys can 

between VDE electronic appliances will not cause different be used to encrypt and decrypt a set of information for a 

electronic appliances to use different time components). 30 limited period of time, thus requiring re-registration or the 

Different portions of the RTC 528 output may be used to receipt of new permissions or the passing of audit 

provide keys with different valid durations, or some toler- information, without which new keys are not provided for 

ance can be built into the process to try several different key user use. Time aged keys can also be used to improve system 

values. For example, a "time granularity" parameter can be security since one or more keys would be automatically 

adjusted to provide time tolerance in terms of days, weeks, 35 replaced based on the time ageing criteria — and thus, crack- 

01 any other time period. As one example, if the "time ing secure database 610 and locating one or more keys may 

granularity" is set to 2 days, and the tolerance is ±2 days, have no real value. Still another advantage of using time 

then three real-time input values can be tried as input to the aged keys is that they can be generated dynamically — 

convolution algorithm. Each of the resulting key values may thereby obviating the need to store decryption keys in 

be tried to determine which of the possible keys is actually 40 secondary and/or secure memory. 

used. In this example, the keys will have only a 4 day life A "time aged key" in the preferred embodiment is not a 

span. "true key" that can be used for encryption/decryption, but 

FIG. 63 shows how an appropriate convoluted key may be rather is a piece of information that a PPE 650, in conjunc- 

picked in order to compensate for skew between the user's tion with other information, can use to generate a "true key." 

RTC 528 and the producer's RTC 528. A sequence of 45 This other information can be time -based, based on the 

convolution keys 2862(a-e) may be generated by using particular "ID" of the PPE 650, or both. Because the "true 

different input values 2881(a-e), each derived from the site key" is never exposed but is always generated within a 

ID 2821 and the RTC 528 value plus or minus a differential secure PPE 650 environment, and because secure PPEs are 

(e.g., -2 days, -1 days, no delta, +1 days, +2 days). The required to generate the "true key," VDE 100 can use "time 

convolution steps 2Sll(a~e) are used to generate the 50 aged" keys to significantly enhance security and flexibility 

sequence of keys 2862(a-e). of the system 

Meanwhile, the creator site may use the convolution step The process of "aging'* a key in the preferred embodiment 

2871(z) based on his RTC 528 value (adjusted to correspond involves generating a time- aged "true key" that is a function 

to the intended validity time for the key) to generate a of: (a) a "true key," and (b) some other information (e.g., real 

convoluted key 2862(z), which may then be used to generate 55 time parameters, site ID parameters, etc.) This information 

the content key 2863 in the object's PERC 808. To decrypt is combined/transformed (e.g., using the "key convolution" 

the object's content, the user site may use each of its techniques discussed above) to recover or provide a "true 

sequence of convolution keys 2862(a-e) to attempt to gen- key."Sincc thc "true key" can be recovered, this avoids 

erate the master content key 810. When this is attempted, as having to store the "true key" within PERC 808, and allow 

long as the RTC 538 of the creator site is within acceptable 60 different "true keys" to correspond to thc same information 

tolerance of the RTC 528 at the user site, one of keys within PERC 808. Because the "true key" is not stored in the 

2862(a-e) will match key 2862(z) and the decryption will be PERC 808, access to the PERC does not provide access to 

successful. In this example, matching is determined by the information protected by the "true key." Thus, "time 

validity of decrypted output, not by direct comparison of aged" keys allows content creators/providers to impose a 

keys. 65 limitation (e.g., site based and/or time based) on information 

Key convolution as described above need not use both site access that is, in a sense, "external of or auxiliary to the 

ID and time as a value. Some keys may be generated based permissioning provided by one or more PERCs 808. For 
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example, a "time aged" key may enforce an additional time time- aged key block, as specified by the object creator 

limitation on access to certain protected information, this during the object configuration process, or where 

additional time limitation being independent of any infor- appropriate, a distributor or client administrator, 

mation or permissioning contained within the PERC 808 and "Time aged" keys can also be used as part of protocols to 

being instead based on one or more time and/or site ID s provide secure communications between PPEs 650. For 

values example, instead of providing "true" keys to PPE 650 for 

As one example, time-aged decryption keys may be used communications, VDE 100 may provide only "partial" com- 

to allow the purchaser of a "trial subscription" of an elec- munication keys t0 ^ PPE . « part ial" keys may be 

Ironically published newspaper to access each edition of the ided tQ ppE 650 durin initialization, for example. A 

paper for a penod of one week after which the decryption detcrmincd ^ rithm ducc ^ k » for ^ to 

keys will no longer work. In this example, the user would r 4/J * c r 

need to purchase one or more new PERCs 808, or receive an ^crypt/decrypt mfonnation for secure communications, 

update to an existing one or more permissions records, to ^ ? re ^f "~^ g0 ^ 1 m ™ age " ^ k T Same 

access editions other than the ones from that week Access to wa * m ail PPEs 650 > or PPEs 650 caD be required to contact 

those other editions which might be handled with a totally a administrator at some predetermined time so a new 

different pricing structure (e.g., a "regular" subscription rate 15 set of P artial communications keys can be downloaded to the 

as opposed to a free or minimal "trial" subscription rate). PPEs - If ^ PPE 650 does n Qt generate or otherwise obtain 

In the preferred embodiment, time -aged-based "true "new" partial keys, then it will be disabled from communi- 

keys" can be generated using a one-way or invertible "key eating with other PPEs (a further, "fail safe" key may be 

convolution" function. Input parameters to the convolution provided to ensure that the PPE can communicate with a 

function may include the supplied time-aged keys; user 20 VDE administrator for reinitialization purposes). Two sets of 

and/or site specific values; a specified portion (e.g., a certain partial keys can be maintained within a PPE 650 to allow a 

number of high order bits) of the time value from an RTC fixed amount of overlap time across all VDE appliances 600. 

528 (if present) or a value derived from such time value ia The older of the two sets of partial keys can be updated 

a predefined manner; and a block or record identifier that periodically. 

may be use d to ensure that each time aged key is unique. 25 The following additional types of keys (to be discussed 

The output of the "key convolution" function may be a "true below) can also be "aged" in the preferred embodiment: 

key" that is used for decryption purposes until discarded. individual message keys (i.e., keys used for a particular 

Running the function with a time- aged key and inappropri- message), 

ate time values typically yields a useless key that will not administrative, stationary and travelling object shared 

decrypt. 30 kevs? 

Generation of a new time aged key can be triggered based , . , , A 

, - . i f 1 i • / secure database keys, and 

on some value of elapsed, absolute or relative time (e.g., . , 

based on a real time value from a clock such as RTC 528). pnvale bod y content kevs - 

At that time, the convolution would produce the wrong key Initial Installation Key Management 

and decryption could not occur until the time-aged key is 35 _ T _ . . t , _ . 

updated. The criteria used to determine when a new "time , FIG * 64 shows thc fl ° w of ™ w ~^\ or m f Cr \ 

aged key" is to be created may itself be changed based on ke y s *™ m Z J***^ ° f * pnttmd 

time or some other input variable to provide yet another cmbodimc^ tte PPE 6M watains a ac cureno^vc^ekey 

level of security. Thus, the convolution function and/or the stora 8 e ? 802 ( e * SPU ^ 534 ? °I 

event invoking it may change, shift or employ a varying 40 Protected storage maintained by HPE 655) that is localized 

quantity as a parameter. Wlth ke y s generated by the manufacturer and by the PPE 



One example of the use of time-aged keys is as follows: 



1) A creator makes a "true" key, and encrypts content with ™e manufacturer possesses (i.e., knows, and protects 
it from disclosure or modification) one or more public key 

2) A creator performs a "reverse convolution" to yield a 45 2811/private key 2812 key pairs used for signing and 
"time aged key" using, as input parameters to the "reverse validating site identification certificates 2821. For each site, 
convolution": tne manufacturer generates a site ID 2821 and list of site 

a) the "true" key, characteristics 2822. In addition, the manufacturer possesses 

b) a time parameter (e.g., valid high-order time bits of the P ublic ke y s 2813 > 2514 for validating load modules and 
RTC 528), and 50 initialization code downloads. To enhance security, there 

c) optional other information (e.g., site ID and/or user ID). ma y be a plurality of such certification keys, and each PPE 

3) The creator distributes the "time-aged key" to content 650 ma y be initialized using only a subset of such keys of 
users (the creator may also need to distribute the convo- eacn tv P e * 

lution algorithm and/or parameters if she is not using a As part of the initialization process, the PPE 650 may 

convolution algorithm already available to the content 55 generate internally or the manufacturer may generate and 

users' PPE 650). su Ppty> °ne or more pairs of site-specific public keys 2815 

4) The content user's PPE 650 combines: and private keys 2816. These are used by the PPE 650 to 

a) "time-aged" key prove its identity. Similarly, site-specific database key(s) 

b) high-order time bits 2817 for the site are generated, and if needed (i.e., if a 

c) required other information (same as 2c). 60 Random Number Generator 542 is not available), a random 
It performs a convolution function (i.e., the inverse of initialization seed 2818 is generated. 

"reverse convolution" algorithm in step (2) above) to obtain The initialization may begin by generating site ID 2821 

the "true" key. If the supplied time and/or other information and characteristics 2822 and the site public key 2815/private 

is "wrong," the convolution function will not yield the "true" key 2816 pair(s). These values are combined and may be 

key, and therefore content cannot be decrypted. 65 used to generate one or more site identity certificates 2823. 

Any of the key blocks associated with VDE objects 300 The site identity certificates 2823 may be generated by the 

or other items can be either a regular key block or a public key generation process 2804, and may be stored both 
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in the PPE's protected key storage 2802 and in the manu- 
facturer's VDE site certificate database 2803. 

The certification process 2804 may be performed either 
by the manufacturer or internally to the PPE 650. If per- 
formed by the PPE 650, the PPE will temporarily receive the 
identity certification private key(s) 2812, generate the cer- 
tificate 2823, store the certificate in local key storage 2802 
and transmit it to the manufacturer, after which the PPE 650 
must erase its copy of the identity certification private key(s) 
2812. 

Subsequently, initialization may require generation, by 
the PPE 650 or by the manufacturer, of site-specific database 
key(s) 2817 and of site-specific seed value(s) 2818, which 
are stored in the key storage 2802. In addition, the download 
certification key(s) 2814 and the load module certification 
key(s) 2813 may be supplied by the manufacturer and stored 
in the key storage 2802. These may be used by the PPE 650 
to validate all further communications with external entities. 

At this point, the PPE 650 may be further initialized with 
executable code and data by downloading information cer- 
tified by the load module key(s) 2813 and download key(s) 
2814. In the preferred embodiment, these keys may be used 
to digitally sign data to be loaded into the PPE 650, 
guaranteeing its validity, and additional key(s) encrypted 
using the site-specific public key(s) 2815 may be used to 
encrypt such data and protect it from disclosure. 

Installation and Update Key Management 

FIG. 65 illustrates an example of farther key installation 
either by the manufacturer or by a subsequent update by a 
VDE administrator. The manufacturer or administrator may 
supply initial or new values for private header key(s) 2831, 
external communication key(s) 2832, administrative object 
keys 2833, or other shared key(s) 2834. These keys may be 
universe-wide in the same sense as the global certification 
keys 2811, 2813, and 2814, or they may be restricted to use 
within a defined group of VDE instances. 

To perform this installation, the installer retrieves the 
destination site's identity certificate^) 2823, and from that 40 
extracts the site public key(s) 2815, These key(s) may be 
used in an encryption process 2841 to protect the keys being 
installed. The key(s) being installed are then transmitted 
inside the destination site's PPE 650. Inside the PPE 650, the 
decryption process 2842 may use the site private key(s) 
2816 to decrypt the transmission. The PPE 650 then stores 
the installed or updated keys in its key storage 2802. 
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610. In subsequent access to the content object 850, the 
PERC 808 may be retrieved from the secure database 610, 
decrypted with database key(s) 2817, and used directly, 
rather than being extracted from administrative object 870. 

FIG. 67 shows the similar process involving a traveling 
object 860. The principal distinction between FIGS. 66 and 
67 is that the PERC 808 is stored directly within the 
traveling object 860, and therefore may be used immediately 
after the decryption process 2843 to provide a private header 
key(s) 2831. This private header key 2831 is used to process 
content within the traveling object 860. 

Secret-Key Variations 

FIGS. 64 through 67 illustrate the preferred public-key 
embodiment, but may also be used to help understand the 
secret-key versions. In secret-key embodiments, the certifi- 
cation process and the public key encryptions/decryptions 
are replaced with private-key encryptions, and the public 
key/private-key pairs are replaced with individual secret 
keys that are shared between the PPE 650 instance and the 
other parties (e.g., the load module suppliers), the PPE 
manufacturer). In addition, the certificate generation process 
2804 is not performed in secret-key embodiments, and no 
site identity certificates 2823 or VIDE certificate database 
2803 exist. 

Key Types 

The detailed descriptions of key types below further 
explain secret-key embodiments; this summary is not 
intended as a complete description. The preferred embodi- 
ment PPE 650 can use different types of keys and/or 
different "shared secrets" for different purposes. Some key 
types apply to a Public-Key/Secret Key implementation, 
other keys apply to a Secret Key only implementation, and 
still other key types apply to both. The following table lists 
examples of various key and "shared secret" information 
used in the preferred embodiment, and where this informa- 
tion is used and stored: 



Key/Secret Information Used in PK or 

Type Non-PK Example Storage Location (a) 



Object-Specific Key Use 

FIGS. 66 and 67 illustrate the use of keys in protecting 
data and control information associated with VDE objects 
300. 

FIG. 66 shows use of a stationary content object 850 
whose control information is derived from an administrative 
object 870. The objects may be received by the PPE 650 
(e.g., by retrieval from an object repository 728 over a 
network or retrieved from local storage). The administrative 
object decryption process 2843 may use the private header 
kcy(s) 2815 to decrypt the administrative object 870, thus 
retrieving the PERC 808 governing access to the content 
object 850. The private body key(s) 810 may then be 
extracted from the PERC 808 and used by the content 
decryption process 2845 to make the content available 
outside the PPE 650. In addition, the database key(s) 2817 
may be used by the encryption process 2844 to prepare the 
PERC for storage outside the PPE 650 in the secure database 



50 



55 



45 



65 



Master Key(s) (may 
include some of the 
specific keys mentioned 
below) 

Manufacturing Key 
Ceitification key pair 
Public/private key pair 

Initial secret key 
PPE manufacturing ID 
Site ID, shared code, 
shared keys and shared 
secrets 
Download 
Authorization key 
External 

communication keys 
and other info 
Administrative object 
keys 

Stationary object keys 
Traveling object shared 
keys 

Secure database keys 
Private body keys 



Both 



Both (PK 
optional) 
PK 

PK 



Non-PK 
Non-PK 
Both 



Both 



Both 



Both 
Both 



Both 
Both 



PPE 

Manufacturing facility 
VDE administrator 

PPE (PK case) 
Manufacturing facility 
PPE 

Certification repository 
PPE 

Certification repository 

(Public Key only) 

PPE 

PPE 

PPE 



PPE 

VDE administrator 
PPE 

Secure Database 

Permission record 

Permission record 
Permission record 

PPE 

Secure database 
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■continued 



Key/Secret Information 
Type 


Used in PK. 01 
Non-PK 


Example Storage Location^) 






Some objects 


Content keys 


Both 


Secure database 






Some objects 


Authorization shared 


Both 


Permission record 


secrets 






Secure Database Back 


Both 


PPE 


up keys 




Secure database 



Master Keys 

A "master" key is a key used to encrypt other keys. An 
initial or "master" key may be provided within PPE 650 for 
communicating other keys in a secure way. During initial- 
ization of PPE 650, code and shared keys are downloaded to 
the PPE. Since the code contains secure convolution algo- 
rithms and/or coefficients, it is comparable to a "master key." 
The shared keys may also be considered "master keys." 

If public-key cryptography is used as the basis for exter- 
nal communication with PPE 650, then a master key is 
required during the PPE Public-key pair certification pro- 
cess. This master key may be, for example, a private key 
used by the manufacturer or VDE administrator to establish 
the digital certificate (encrypted public key and other infor- 
mation of the PPE), or it may, as another example, be a 
private key used by a VDE administrator to encrypt the 
entries in a certification repository. Once certification has 
occurred, external communications between PPEs 650 may 
be established using the certificates of communicating PPEs. 

If shared secret keys are used as the basis for external 
communications, then an initial secret key is required to 
establish external communications for PPE 650 initializa- 
tion. This initial secret key is a "master key" in the sense that 
it is used to encrypt other keys. A set of shared partial 
external communications keys (see discussion above) may 
be downloaded during the PPE initialization process, and 
these keys are used to establish subsequent external PPE 
communications. 

Manufacturing Key 

A manufacturing key is used at the time of PPE manu- 
facture to prevent knowledge by the manufacturing staff of 
PPE-specific key information that is downloaded into a PPE 
at initialization time. For example, a PPE 650 that operates 
as part of the manufacturing facility may generate informa- 
tion for download into the PPE being initialized. This 
information must be encrypted during communication 
between the PPEs 650 to keep it confidential, or otherwise 
the manufacturing staff could read the information, A manu- 
facturing key is used to protect the information. The manu- 
facturing key may be used to protect various other keys 
downloaded into the PPE such as, for example, a certifica- 
tion private key, a PPE public/private key pair, and/or other 
keys such as shared secret keys specific to the PPE. Since the 
manufacturing key is used to encrypt other keys, it is a 
"master key." 

A manufacturing key may be public-key based, or it may 
be based on a shared secret. Once the information is 
downloaded, the now-initialized PPE 650 can discard (or 
simply not use) the manufacturing key. A manufacturing key 
may be hardwired into PPE 650 at manufacturing time, or 
sent to the PPE as its first key and discarded after it is no 
longer needed. As indicated in the table above and in the 
preceding discussion, a manufacturing key is not required if 
PK capabilities are included in the PPE. 
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Certification Key Pair 

A certification key pair may be used as part of a "certi- 
fication" process for PPEs 650 and VDE electronic appli- 
ances 600. This certification process in the preferred 
embodiment may be used to permit a VDE electronic 
appliance to present one or more "certificates" authenticat- 
ing that it (or its key) can be trusted. As described above, this 
"certification" process may be used by one PPE 650 to 
"certify" that it is an authentic VDE PPE, it has a certain 

1 level of security and capability set (e.g., it is hardware based 
rather than merely software based), etc. Briefly, the "certi- 
fication" process may involve using a certificate private key 
of a certification key pair to encrypt a message including 
another VDE node's public-key. The private key of a cer- 
tification key pair is preferably used to generate a PPE 
certificate. It is used to encrypt a public-key of the PPE, A 
PPE certificate can either be stored in the PPE, or it may be 
stored in a certification repository. 

( Depending on the authentication technique chosen, the 
public key and the private key of a certification key pair may 
need to be protected. In the preferred embodiment, the 
certification public key(s) is distributed amongst PPEs such 
that they may make use of them in decrypting certificates as 

. an aspect of authentication. Since, in the preferred 
embodiment, this public key is used inside a PPE 650, there 
is no need for this public key to be available in plaintext, and 
in any event it is important that such key be maintained and 
transmitted with integrity (e.g., during initialization and/or 

( update by a VDE administrator). If the certification public 
key is kept confidential (i.e., only available in plaintext 
inside the PPE 650), it may make cracking security much 
more difficult. The private key of a certification key pair 
should be kept confidential and only be stored by a certifying 

, authority (Le., should not be distributed). 

In order to allow, in the preferred embodiment, the ability 
to differentiate installations with different levels/degrees of 
trustedness/security, different certification key pairs may be 
used (e.g., different certification keys may be used to certify 

, SPEs 503 then are used to certify HPEs 655). 

PPE Public/Private Key Pair 

In the preferred embodiment, each PPE 650 may have its 
own unique "device" (and/or user) public/private key pair. 

45 Preferably, the private key of this key pair is generated 
within the PPE and is never exposed in any form outside of 
the PPE. Thus, in one embodiment, the PPE 650 may be 
provided with an internal capability for generating key pairs 
internally. If the PPE generates its own public-key crypto- 

50 system key pairs internally, a manufacturing key discussed 
above may not be needed. If desired, however, for cost 
reasons a key pair may be exposed only at the time a PPE 
650 is manufactured, and may be protected at that time using 
a manufacturing key. Allowing PPE 650 to generate its 

55 public key pair internally allows the key pair to be 
concealed, but may in some applications be outweighed by 
the cost of putting a public-key key pair generator into PPE 
650. 

60 Initial Secret Key 

The initial secret key is used as a master key by a secret 
key only based PPE 650 to protect information downloaded 
into the PPE during initialization. It is generated by the PPE 
650, and is sent from the PPE to a secure manufacturing 
65 database encrypted using a manufacturing key. The secure 
database sends back a unique PPE manufacturing ID 
encrypted using the initial secret key in response. 
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The initial secret key is likely to be a much longer key 
than keys used for "standard" encryption due to its special 
role in PPE initialization. Since the resulting decryption 
overhead occurs only during the initialization process, mul- 
tiple passes through the decryption hardware with selected 
portions of this key arc tolerable. 

PPE Manufacturing ID 

The PPE manufacturing ID is not a "key," but does fall 
within the classic definition of a "shared secret." It prefer- 
ably uniquely identifies a PPE 650 and may be used by the 
secure database 610 to determine the PPE's initial secret key 
during the PPE initialization process. 

Site ID, Shared Code, Shared Keys and Shared 
Secrets 

The VDE site ID along with shared code, keys and secrets 
are preferably either downloaded into PPE 650 during the 
PPE initialization process, or are generated internally by a 
PPE as part of that process. In the preferred embodiment, 
most or all of this information is downloaded. 

The PPE site ID uniquely identifies the PPE 650. The site 
ID is preferably unique so as to uniquely identify the PPE 
650 and distinguish that PPE from all other PPEs. The site 
ID in the preferred embodiment provides a unique address 
that may be used for various purposes, such as for example 
to provide "address privacy" functions. In some cases, the 
site ID may be the public key of the PPE 650, In other cases, 
the PPE site ID may be assigned during the manufacturing 
and/or initialization process. In the case of a PPE 650 that is 
not public-key-capable, it would not be desirable to use the 
device secret key as the unique site ID because this would 
expose too many bits of the key-and therefore a different 
information string should be used as the site ID. 

Shared code comprises those code fragments that provide 
at least a portion of the control program for the PPE 650. In 
the preferred embodiment, a basic code fragment is installed 
during PPE manufacturing that permits the PPE to bootstrap 
and begin the initialization process. This fragment can be 
replaced during the initialization process, or during subse- 
quent download processing, with updated control logic. 

Shared keys may be downloaded into PPE 650 during the 
initialization process. These keys may be used, for example, 
to decrypt the private headers of many object structures. 

When PPE 650 is operating in a secret key only mode, the 
initialization and download processes may import shared 
secrets into the PPE 650. These shared secrets may be used 
during communications processes to permit PPEs 650 to 
authenticate the identity of other PPEs and/or users. 

Download Authorization Key 

Tbe download authorization key is received by PPE 650 
during the initialization download process. It is used to 
authorize further PPE 650 code updates, key updates, and 
may also be used to protect PPE secure database 610 backup 
to allow recovery by a VDE administrator (for example) if 
the PPE fails. It may be used along with the site ID, time and 
convolution algorithm to derive a site ID specific key. The 
download authorization key may also be used to encrypt the 
key block used to encrypt secure database 610 backups. It 
may also be used to form a site specific key that is used to 
enable future downloads to the PPE 650. This download 
authorization key is not shared among all PPEs 650 in the 
preferred embodiment; it is specific to functions performed 
by authorized VDE administrators. 
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External Communications Keys and Related Secret 
and Public Information 

There are several cases where keys are required when 
s PPEs 650 communicate. The process of establishing secure 
communications may also require the use of related public 
and secret information about the communicating electronic 
appliances 600. The external communication keys and other 
information are used to support and authenticate secure 
10 communications. These keys comprise a public-key pair in 
the preferred embodiment although shared secret keys may 
be used alternatively or in addition. 

Administrative Object Keys 

15 In the preferred embodiment, an administrative object 
shared key may be used to decrypt the private header of an 
administrative object 870. In the case of administrative 
objects, a permissions record 808 may be present in the 
private header. In some cases, the permissions record 808 

20 may be distributed as (or within) an administrative object 
that performs the function of providing a right to process the 
content of other administrative objects. The permissions 
record 808 preferably contains the keys for the private body, 
and the keys for the content that can be accessed would be 

25 budgets referenced in that permissions record 808. The 
administrative object shared keys may incorporate time as a 
component, and may be replaced when expired. 

Stationary Object Keys 

30 

A stationary object shared key may be used to decrypt a 
private header of stationary objects 850. As explained above, 
in some cases a permissions record 808 may be present in 
the private header of stationary objects. If present, the 
35 permissions record 808 may contain the keys for the private 
body but will not contain the keys for the content. These 
shared keys may incorporate time as a component, and may 
be replaced when expired. 

40 Traveling Object Shared Keys 

A traveling object shared key may be used to decrypt the 
private header of traveling objects 860. In the preferred 
embodiment, traveling objects contain permissions record 
808 in their private headers. The permissions record 808 
45 preferably contains the keys for the private body and the 
keys for the content that can be accessed as permitted by the 
permissions record 808. These shared keys may incorporate 
time as a component, and may be replaced when expired, 

so Secure Database Keys 

PPE 650 preferably generates these secure database keys 
and never exposes them outside of the PPE. They are 
site -specific in the preferred embodiment, and may be 

5S " aged" as described above. As described above, each time an 
updated record is written to secure database 610, a new key 
may be used and kept in a key list within the PPE. Periodi- 
cally (and when the internal list has no more room), the PPE 
650 may generate a new key to encrypt new or old records. 

6Q A group of keys may be used instead of a single key, 
depending on the size of the secure database 610. 

Private Body Keys 

Private body keys are unique to an object 300, and are not 
65 dependent on key information shared between PPEs 650. 
They are preferably generated by the PPE 650 at the time the 
private body is encrypted, and may incorporate real-time as 
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a component to "age" them. They are received in permis- Keyless seals may be employed as check values in 

sions records 808, and their usage may be controlled by database records (e.g., in PERC 808) and similar applica- 

budgets. tions. A keyless seal may be computed based on the content 

of the body of the record, and the seal stored with the rest 

Content Keys 5 0 f the record. The combination of seal and record may be 

Content Keys are unique to an object 300, and are not encrypted to protect it in storage. If someone modifies the 

dependent on key information shared between PPEs 650. encrypted record without knowing the encryption key (either 

They are preferably generated by the PPE 650 at the time the in ^ P art representing the data or the part representing the 

content is encrypted. They may incorporate time as a com- seal )> the decrypted content will be different, and the 

ponent to "age" them. They are received in permissions 10 decrypted check value will not match the digest computed 

records 808, and their usage may be controlled by budgets. & om me record's data. Even though the hash algorithm is 

known, it is not feasible to modify both the record's data and 

Authorization Shared Secrets its seal to correspond because both are encrypted. 

Access to and use of information within a PPE 650 or c Ke y ed seals ma y be employed as protection for data 

within a secure database 610 may be controlled using 15 stored outside a protected envirornnent wittout encryption, 

authorization "shared secrets" rather than keys. Authoriza- °/ as a validity proof between two protected environments, 

tion shared secrets may be stored within the records they ^ keved seal 1S imputed similarly to a keyless seal except 

authorize (permissions records 808, budget records, etc.). a initial value is logically prefixed to the data 

The authorization shared secret may be formulated when the bem S ™ e value de P ends both on ^ 

corresponding record is created. Authorization shared 20 secret and medata, ano^ 

secrets can be generated by an authorizing PPE 650, and 10 correspond to modified data even though the data itself is 

may be replaced when record updates occur. Authorization visiblc toan attac ^ cr - A kcvc( J scal mav P rotcct data m 

shared secrets have some characteristics associated with storage with a single secret value or may protect data m 

"capabilities" used in capabilities based operating systems. 5 transit bctwccn two environments that share a single secret 

Access tags (described below) are an important set of value. 

authorization shared secrets in the preferred embodiment. The choice of keys or keyless seals depends on the nature 

of the data being protected and whether it is additionally 

Backup Keys protected by encryption. 

As described above, the secure database 610 backup 30 Tagging 

consists of reading all secure database records and current ^ . « , <• * « . 

audit "roll ups" stored in both PPE 650 and externally. Then, Ta SS m 8 IS P articularl y for supporting the secure 

the backup process decrypts and re-encrypts this information stora S e of ^patent component assembly and related infor- 

using a new set of generated keys. Hiese keys, the time of maUon on secondary storage memory 652. Integrated use of 

the backup, and other appropriate information to identify the 35 mfonnation tagging* and encryption strategies allows use 

backup, may be encrypted multiple times and stored with the of inexpensive mass storage devices to securely store infor- 

previously encrypted secure database files and roll up data matl ° Q mat > in P art enablcs > lunits ^ 0l e TC ™ T * S ih * 

within the backup files. Tliese files may then all be encrypted confip ration management and operation of a VDE node 

using a "backup key" that is generated and stored within md thc ^ of VDE Pr° tcctc d content. 

PPE 650. This backup key 500 may be used by the PPE to 40 WhcD encrypted or otherwise secured information is 

recover a backup if necessary. The backup keys may also be delivered into a user's secure VDE processing area (e.g., 

securely encrypted (e.g., using a download authentication PPE 650 )> a portion of this information can be used as a 

key and/or a VDE administrator public key) and stored " ta g" that & first decrypted or otherwise unsecured and then 

within the backup itself to permit a VDE administrator to compared to an expected value to confirm that the informa- 

recover the backup in case of PPE 650 failure. 45 tion represents expected information. The tag thus can be 

used as a portion of a process confirming the identity and 

Cryptographic Sealing correctness of received, VDE protected, information. 

Sealing is used to protect the integrity of information T^ classes of tags that may be included in the control 

when it may be subjected to modifications outside the structures of the preferred embodiment: 

control of the PPE 650, either accidentally or as an attack on 50 access tags 

the VDE security. Two specific applications may be the validation tags 

computation of check values for database records and the correlation tags, 

protection of data blocks that are swapped out of an SPE These tags have distinct purposes. 

500. An access tag may be used as a "shared secret" between 

There are two types of sealing: keyless sealing, also 55 VDE protected elements and entities authorized to read 

known as cryptographic hashing, and keyed sealing. Both and/or modify the tagged element(s). The access tag may be 

employ a cryptographically strong hash function, such as broken into separate fields to control different activities 

MD5 or SHA Such a function takes an input of arbitrary independently. If an access tag is used by an element such 

size and yields a fixed-size hash, or "digest." The digest has as a method core 1000 1 , administrative events that affect 

the property that it is infeasible to compute two inputs that 60 such an element must include the access tag (or portion of 

yield the same digest, and infeasible to compute one input the access tag) for the affected elements) and assert that tag 

that yields a specific digest value, where "infeasible" is with when an event is submitted for processing. If access tags are 

reference to a work factor based on the size of the digest maintained securely (e.g., created inside a PPE 650 when the 

value in bits. If, for example, a 256-bit hash function is to be elements are created, and only released from PPE 650 in 

called strong, it must require approximately on average 65 encrypted structures), and only distributed to authorized 

10~38(2 A 128) trials before a duplicated or specified digest parties, modification of structures can be controlled more 

value is likely to be produced. securely. Of course, control structures (e.g., PERCs 808) 
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may further limit or qualify modifications or other actions 
expressed in administrative events. 

Correlation tags are used when one element references 
another element. For example, a creator might be required 
by a budget owner to obtain permission and establish a 5 
business relationship prior to referencing their budget within 
the creator's PERCs. After such relationship was formed, the 
budget owner might transmit one or more correlation tags to 
the creator as one aspect of allowing the creator to produce 
PERCs that reference the budget owner's budget. 10 

Validation tags may be used to help detect record substi- 
tution attempts on the part of a tamperer. 

In some respects, these three classes of tags overlap in 
function. For example, a correlation tag mismatch may 
prevent some classes of modification attempts that would is 
normally be prevented by an access tag mismatch before an 
access tag check is performed. The preferred embodiment 
may use this overlap in some cases to reduce overhead by, 
for example, using access tags in a role similar to validation 
tags as described above. 20 

In general, tagging procedures involve changing, within 
SPE 503, encryption key(s), securing techniques(s), and/or 
providing specific, stored tag(s). These procedures can be 
employed with secure database 610 information stored on 
said inexpensive mass storage 652 and used within a hard- 25 
ware SPU 500 for authenticating, decrypting, or otherwise 
analyzing, using and making available VDE protected con- 
tent and management database information. Normally, 
changing validation tags involves storing within a VDE 
node hardware (e.g., the PPE 650) one or more elements of 30 
information corresponding to the tagging changes. Storage 
of information outside of the hardware SPE's physically 
secure, trusted environment is a highly cost savings means 
of secure storage, and the security of important stored 
management database information is enhanced by this tag- 35 
ging of information. Performing this tagging "change" fre- 
quently (for example, every time a given record is 
decrypted) prevents the substitution of "incorrect" informa- 
tion for "correct" information, since said substitution will 
not carry information which will match the tagging infor- 40 
mation stored within the hardware SPE during subsequent 
retrieval of the information. 

Another benefit of information tagging is the use of tags 
to help enforce and/or verify information and/or control 
mechanisms in force between two or more parties. If infor- 45 
mation is tagged by one party, and then passed to another 
party or parties, a tag can be used as an expected value 
associated with communications and/or transactions 
between the two parties regarding the tagged information. 
For example, if a tag is associated with a data element that 50 
is passed by Party A to Party B, Party B may require Party 
A to prove knowledge of the correct value of at least a 
portion of a tag before information related to, and/or part of, 
said data element is released by Party B to Party A, or vice 
versa. In another example, a tag may be used by Party A to 55 
verify that information sent by Party B is actually associated 
with, and/or part of, a tagged data element, or vice versa. 

Establishing A Secure, Authenticated, 
Communication Channel 

60 

From time to time, two parties (e.g., PPEs A and B), will 
need to establish a communication channel that is known by 
both parties to be secure from eavesdropping, secure from . 
tampering, and to be in use solely by the two parties whose 
identifies are correctly known to each other. $5 

The following describes an example process for estab- 
lishing such a channel and identifies how the requirements 
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for security and authentication may be established and 
validated by the parties. The process is described in the 
abstract, in terms of the claims and belief each party must 
establish, and is not to be taken as a specification of any 
particular protocol. In particular, the individual sub-steps of 
each step are not required to be implemented using distinct 
operations; in practice, the establishment and validation of 
related proofs is often combined into a single operation. 

The sub-steps need not be performed in the order detailed 
below, except to the extent that the validity of a claim cannot 
be proven before the claim is made by the other party. The 
steps may involve additional communications between the 
two parties than are implied by the enumerated sub-steps, as 
the "transmission" of information may itself be broken into 
substeps. Also, it is not necessary to protect the claims or the 
proofs from disclosure or modification during transmission. 
Knowledge of the claims (including the specific communi- 
cation proposals and acknowledgements thereof) is not 
considered protected information. Any modification of the 
proofs will cause the proofs to become invalid and will cause 
the process to fail. 

Standard public-key or secret-key cryptographic tech- 
niques can be used to implement this process (e.g., X.509, 
Authenticated Diffie-Hellman, Kerberos). The preferred 
embodiment uses the three-way X.509 public key protocol 
steps. 

The following may be the first two steps in the example 
process: 

A. (precursor step): Establish means of creating validat- 
able claims by A 

B. (precursor step): Establish means of creating validat- 
able claims by B 

These two steps ensure that each party has a means of 
making claims that can be validated by the other party, for 
instance, by using a public key signature scheme in which 
both parties maintain a private key and make available a 
public key that itself is authenticated by the digital signature 
of a certification authority. 

The next steps may be: 

A (proposal step): 

1. Determine B's identity 

2. Acquire means of validating claims made by B 

3. Create a unique identity for this specific proposed com- 
munication 

4. Create a communication proposal identifying the parties 
and the specific communication 

5. Create validatable proof of A's identity and the origin of 
the communication proposal 

6. Deliver communication proposal and associated proof to 
B. 

These steps establish the identity of the correspondent 
party B and proposes a communication. Because establish- 
ment of the communication will require validation of claims 
made by B, a means must be provided for A to validate such 
claims. Because the establishment of the communication 
must be unique to a specific requirement by A for 
communication, this communication proposal and all asso- 
ciated traffic must be unambiguously distinguishable from 
all other such traffic. Because B must validate the proposal 
as a legitimate proposal from A, a proof must be provided 
that the proposal is valid. 

The next steps may be as follows: 

B (acknowledgement step): 

1. Extract A's identity from the communication proposal 

2. Acquire means of validating claims made by A 

3. Validate A*s claim of identity and communication pro- 
posal origin 
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4. Determine the unique identification of the communication VDE object are redistributed to a different PPE 650. Some 
proposal VDE objects may require that all object-related information 

5. Determine that the communication proposal does not be delivered (e.g., it's possible to "sell" all rights to the 
duplicate an earlier proposal object). However, some VDE objects 300 may prohibit such 

6. Create an acknowledgement identifying the specific com- $ a transfer. In the case of ownership transfer, the original 
mimication proposal providers for a VDE object 300 may need to be contacted by 

7. Create validatable proof of B's identity and the origin of me new owner> in f ormed of me transfer, and validated using 
the acknowledgement an authorization shared secret that accompanies 

8. Deliver the acknowledgement and associated proof to A. reautDOrization> before transfer of ownership can be com- 
These steps establish that party B has received A s leted 

communication proposal and is prepared to act on it. p 

Because B must validate the proposal, B must first determine When an electronic appliance 600 receives a component 
its origin and validate its authenticity. B must ensure that its assembly, an encrypted part of the assembly may contain a 
response is associated with a specific proposal, and that the value that is known only to the party or PPE 650 that 
proposal is not a replay. If B accepts the proposal, it must supplied the assembly. This value may be saved with infor- 
prove both B's own identity and that B has received a 15 mation that must eventually returned to the assembly sup- 
specific proposal. plier (e.g., audit, billing and related information). When a 
The next steps may be: component supplier requests that information be reported, 
A (establishment step): the value may be provided by the supplier so that the local 

1. Validate B's claim acknowledgement of A's specific electronic appliance 600 can check it against the originally 
proposal 20 supplied value to ensure that the request is legitimate. When 

2. Extract the identity of the specific communication pro- a new component is received, the value may be checked 
posal from the acknowledgement against an old component to determine whether the new 

3. Determine that the acknowledgement is associated with component is legitimate (e.g., the new value for use in the 
an outstanding communication proposal ne xt report process may be included with the new 

4. Create unique session key to be used for the proposed 25 component), 
communication 

5. Create proof of session key's creation by A Integrity of VDE Security 

6. Create proof of session key's association with the specific 

communication proposal are manv wavs 113 whlch a PPE 650 mi g ht be 

7. Create proof of receipt of B's acknowledgement 30 compromised. The goal of the security provided by VDE 

8. Protect the session key from disclosure in transmission 100 * to reduce the possibihty that the system will be 

9. Protect the session key from modification in transmission compromised, and minimize the adverse effects if it is 

10. Deliver protected session key and all proofs to B. compromised. 

These steps allows A to specify a session key to be The basic cryptographic algorithm that are used to imple- 

associated with all further traffic related to A's specific 35 ment VDE 100 are assumed to be safe (cryptographically 

communication proposal. A must create the key, prove that strong). These include the secret-key encryption of content, 

A created it, and prove that it is associated with the specific public-key signatures for integrity verification, public-key 

proposed communication. In addition, A must prove that the encryption for privacy between PPEs 650 or between a PPE 

session key is generated in response to B's acknowledge- and a administrator, etc. Direct attack on these algo- 

ment of the proposal. The session key must be protected 40 rithms is assumed to be beyond the capabilities of an 

from disclosure of modification to ensure that an attacker attacker. For domestic versions of VDE 100 some of this is 

cannot substitute a different value. probably a safe assumption since the basic building blocks 

_ .... ¥ „ . ^ for control information have sufficiently long keys and are 

Transportability of VDE ^Installations Between su fficiendy proven. 

45 The following risks of threat or attacks may be significant: 

In a preferred embodiment, VDE objects 300 and other rr . . t . - 

. - -c * » j_ . , j » Unauthorized creation or modification of component 

secure information may if appropriate, be transported from ... , , , , x r 

rmn ten. * ^ i • iL • i assemblies (e.g., budgets) 

one PPE 650 to another securely using the various keys v ' 

outlined above. VDE 100 uses redistribution of VDE admin- Unauthorized bulk disclosure of content 

istrative information to exchange ownership of VDE object 50 Compromise of one or more keys 

300, and to allow the portability of objects between elec- Software emulation of a hardware PPE 

tronic appliances 600. Substitution of older records in place of newer records 

The permissions record 808 of VDE objects 300 contains Introduct ion of "rogue" (Le., unauthentic) load modules 
rights information that may be used to determine whether an 

object can be redistributed in whole, in part, or at all. If a 55 Rcplay att 

VDE object 300 can be redistributed, then electronic appli- Defeating "fingerprinting" 

ance 600 normally must have a "budget" and/or other Unauthorized disclosure of individual content items 
permissioning that allows it to redistribute the object. For Redistribution of individual content items, 
example, an electronic appliance 600 authorized to redis- A significant potential security breach would occur if one 
tribute an object may create an administrative object con- 60 or more encryption keys are compromised. As discussed 
taining a budget or rights less than or equal to the budget or above, however, the encryption keys used by VDE 100 are 
rights that it owns. Some administrative objects may be sent sufficiently varied and compartmentalized so that compro- 
to other PPEs 650. A PPE 650 that receives one of the mising one key would have only limited value to an attacker 
administrative objects may have the ability to use at least a in most cases. For example, if a certification private key is 
portion of the budgets, or rights, to related objects. 65 exposed, an attacker could pass the challenge/response pro- 
Transfer of ownership of a VDE object 300 is a special tocol as discussed above but would then confront the next 
case in which all of the permissions and/or budgets for a level of security that would entail cracking either the ini- 
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tialization challenge/response or the external communica- 
tion keys. If the initialization challenge/response security is 
also defeated, the initialization code and various initializa- 
tion keys would also be exposed. However, it would still be 
necessary to understand the code and data to find the shared 
VDE keys and to duplicate the key-generation 
("convolution") algorithms. In addition, correct real time 
clock values must be maintained by the spoof. If the attacker 
is able to accomplish all of this successfully, then all secure 
communications to the bogus PPE would be compromised. 
An object would be compromised if communications related 
to the permissions record 808 of that object are sent to the 
bogus PPE. 

Knowledge of the PPE download authorization key and 
the algorithms that are used to derive the key that encrypts 
the keys for backup of secured database 610 would com- 
promise the entire secured database at a specific electronic 
appliance 600. However, in order to use this information to 
compromise content of VDE objects 300, an understanding 
of appropriate VDE internals would also be required. In a 
preferred embodiment, the private body keys and content 
keys stored in a secured database 610 are "aged" by includ- 
ing a time component. Time is convoluted with the stored 
values to derive the "true keys" needed to decrypt content. 
If this process is also compromised, then object content or 
methods would be revealed. Since a backup of secured 
database 610 is not ever restored to a PPE 650 in the 
preferred embodiment without the intervention of an autho- 
rized VDE administrator, a "bogus" PPE would have to be 
used to make use of this information 

External communication shared keys are used in the 
preferred embodiment in conjunction with a key convolution 
algorithm based on site ID and time. If compromised, all of 
the steps necessary to allow communications with PPEs 650 
must also be known to take advantage of this knowledge. In 
addition, at least one of the administrative object shared keys 
must be compromised to gain access to a decrypted permis- 
sions record 808. 

Compromising an administrative object shared key has no 
value unless the "cracker" also has knowledge of external 
communication keys. All administrative objects are 
encrypted by unique keys exchanged using the shared exter- 
nal communications keys, site ID and time. Knowledge of 
PPE 650 internal details would be necessary to further 
decrypt the content of administrative objects. 

The private header of a stationary object (or any other 
stationary object that uses the same shared key) if 
compromised, may provide the attacker with access to 
content until the shared key "ages" enough to no longer 
decrypt the private header. Neither the private body nor the 
content of the object is exposed unless a permissions record 
808 for that object is also compromised. The private headers 
of these objects may remain compromised until the key 
"ages" enough to no longer decrypt the private header. 

Secure database encryption keys in the preferred embodi- 
ment are frequendy changing and are also site specific. The 
consequences of compromising a secured database 610 file 
or a record depends on the information that has been 
compromised. For example, permissions record 808 contain 
keys for the public body and content of a VDE object 300. 
If a permissions record 808 is compromised, the aspects of 
that object protected by the keys provided by the permis- 
sions record are also compromised — if the algorithm that 
generates the "true keys" is also known. If a private body 
key becomes known, the private body of the object is 
compromised until the key "ages" and expires. If the "aging" 
process for that key is also compromised, the breach is 
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permanent. Since the private body may contain methods that 
are shared by a number of different objects, these methods 
may also become compromised. When the breach is 
detected, all administrative objects that provide budgets and 
permissions record should update the compromised meth- 
ods. Methods stored in secure database 610 are only 
replaced by more recent versions, so the compromised 
version becomes unusable after the update is completed. 

If a content key becomes compromised, the portion of the 
content encrypted with the key is also compromised until the 
key "ages" and expires. If the "aging" process for that key 
also becomes compromised, then the breach becomes per- 
manent. If multiple levels of encryption are used, or portions 
of the content are encrypted with different keys, learning a 
single key would be ^sufficient to release some or all of the 
content. 

If an authorization shared secret (e.g., an access tag) 
becomes known, the record containing the secret may be 
modified by an authorized means if the "cracker" knows 
how to properly use the secret. Generally speaking, the 
external communications keys, the administrative object 
keys and the management file keys must also be "cracked" 
before a shared secret is useful. Of course, any detailed 
knowledge of the protocols would also be required to make 
use of this information. 

In the preferred embodiment, PPE 650 may detect 
whether or not it has become compromised. For example, by 
comparing information stored in an SPE 503 (e.g., summary 
service information) with information stored in secure data- 
base 610 and/or transmitted to a VDE participant (e.g., a 
VDE clearinghouse), discrepancies may become evident. If 
PPE 650 (or a VDE administrator watching its activities or 
communicating with it) detects that it has been 
compromised, it may be updated with an initialization to use 
new code, keys and new encryption/decryption algorithms. 
This would limit exposure to VDE objects 300 that existed 
at the time the encryption scheme was broken. It is possible 
to require the PPE 650 to cease functioning after a certain 
period of time unless new code and key downloads occur. It 
is also possible to have VDE administrators force updates to 
occur. It is also likely that the desire to acquire a new VDE 
object 300 will provide an incentive for users to update their 
PPEs 650 at regular time intervals. 

Finally, the end-to-end nature of VDE applications, in 
which content 108 flows in one direction, generating reports 
and bills 118 in the other, makes it possible to perform 
"back-end" consistency checks. Such checks, performed in 
clearinghouses 116, can detect patterns of use that may or do 
indicate fraud (e.g., excessive acquisition of protected con- 
tent without any corresponding payment, usage records 
without corresponding billing records). The fine grain of 
usage reporting and the ready availability of usage records 
and reports in electronic form enables sophisticated fraud 
detection mechanisms to be built so that fraud-related costs 
can be kept to an acceptable level. 

Integrity of Software-Based PPE Security 

As discussed above in connection with FIG. 10, some 
applications may use a software-based protected processing 
environment 650 (such as a "host event processing environ- 
ment" (HPE) 655) providing a software-based tamper resis- 
tant barrier 674. Software-based tamper resistant barrier 674 
may be created by software executing on a general-purpose 
CPU. Various software protection techniques may be used to 
construct and/or provide software-based tamper resistant 
barrier 674. 

The risks or threat of attacks described above in connec- 
tion with PPE 650 apply to a software-based PPE. An 
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important threat to be countered with respect to a software- niques to study the program as it operates. This analysis 

based tamper resistant barrier 674 is an attack based on a is represented in FIG. 67 A by block 3352 B. 

distributable computer program that can defeat the tamper An attacker can use hardware-based debugging and/or 

resistant barrier wherever the program is run. Since a simulation tools (e.g., an in-circuit emulator, or ICE) to 

software-based tamper resistant barrier 674 typically will 5 follow and/or modify the dynamic execution of pro- 

not be as secure as a hardware-based tamper resistant barrier grams from medium 3370. This technique may be more 

502, it is useful to explore example steps and procedures a effective than the equivalent using software debugging 

"cracker" might use to "'crack* a software"-based tamper and/or simulation tools because it has less potential 

resistant barrier. effect on operation of the programs. This analysis is 

FIGS. 67A and 67B show example "cracking" techniques 10 represented in FIG, 67A by block 3352B. 

a "cracker" might use to attack software-based tamper Such analysis could provide clues and insights into the 

resistant barrier 674. installation materials 3470, the operational materials 3472, 

Referring to FIG. 67A, the software used to create tamper or ^ oth * L . ^ e L . 

resistant barrier 674 may be distributed, for example, on a Another attack technique could focus on the operational 

storage medium 3370 such as a floppy diskette or optical 15 materials 3472 in the form in which they are installed on 

disk (or, this software could be distributed electronically P ers ? nal computer 3372. For exarnp e,one form of analysis 

over network 108 and stored locally in a computer memory). m f ht mvoW * analyzing the onnhsk copy of the installed 

The software distribution medium 3370 provides software l° fx ™™ ««£ r , asso ^ te " at f S^^t? 1 rom P u ^ 

(code and data) for loading into a computing device such as hard ^ 3 ? 16 67B ' block 33 f 4 >' ^ M ^ » 

a general purpose personal computer 3372, for example. 20 presented m FIG 67A as a magnifying glass 3354B. 

Personal computer 3372 may include, for example, a ran- Bcc *™ * e ^stalled operational materials 3472 can be 

dom access memory 3374 and a hard disk 3376. &x&ai \ ed ^ ^puter 3372, the analysis need not be hmited 

, , _ . ,. to analyzing the static information stored on hard disk 3376, 

In one example, the software dutntaUon medium 3370 bu( ^ mvolw performing static and/or dynamic analysis 

might include installaUon materials 3470 i and operational 25 of me executing (see nG . <7B( blocks 3356) 

matenals 3472. The installation materials 3470 may be 335g) ^ of ^ techniques describ ed above could be used 

executed by computer 3372 to instaU the operational mate- tQ m , me operationaI material 3472 t0 yi M 

rials 3472 onto the computer s hard disk 3376. The com- SQUrce ^ or othef more form 3373A mi/ot 

puter 3372 may hen execute the .operational ^matenals 3472 t m fa 3373B ^ ^ ^ /o[ d jc da(a 

from its hard disk 3376 to provide software-based protected 3Q withjn ^ 3374A ^ be aQal d (see p, G 

processing environment 650 and associated software-based ^ magnifying glass 3354A). 

tamper resistant barrier 672. xh c resultirjg code 3373A and/or memory image 

In this example, one attack technique an attacker might 3373B could be carefully analyzed and reviewed (see mag- 
use is to analyze software distribution medium 3370 (see nifying glasses 3354D.3354E) to obtain an understanding of 
FIG. 67B, block 3352). Such analysis can take many forms. 35 both the static and dynamic structure and operation of 

Such analysis could be performed by a combination of operational materials 3272. Dynamic code analysis could 

one or more techniques. Such techniques include, but are not involve, for example, tracing, single-stepping, data, or code 

hmited to, the following: break points of the executing software image, using analysis 

An attacker can manually "dump" and/or disassemble techniques such as described above. The executing software 

listings of the data from medium 3370. This analysis is "° could be modified dynamically (for example, by patching) 

represented in FIG. 67A by magnifying glass 3352A. during normal operation to attempt to bypass its protection 

An attacker can use cryptoanalytic and/or key search onanisms and/or to learn more about how it operates (see 

techniques to decrypt any encrypted data from medium *} G - 67B ' block 336 °- ' he " chan S es " inserted int0 FIG - 

337O J 67A memory image 3373B). 

A *, j A , 45 A further attack technique in this example might involve 

An attacker can use automated or semi-automated disas- . . , „ , , 4 . « j 

, %AtA , f comparing installed operational material 3472 software and 

sembiy tools to explore me functions ot programs data filcs am ^fi crtni PPE 559 

instances to 

stored on medium 3370 by studying the operation and t . c . , , , . . t u . 

a - At 1,, . ri identify important data structures, such as cryptographic 

flow of the assembly language representation of the k ^ „ block 33^ of FIG . 67A f ar f d § 1G , 

blockMsiB 18 * K repreSemed FIG ' 6?Aby so 67B, block 3362). The resulting list of differences 3362B 

00 . could be carefully analyzed (see FIG. 67A's magnifying 

An attacker can use software reverse-engineering tools to glass 3362C) t0 obtain important c i ue s, using analysis 

reconstruct high-level language representations of the techniques such as described above, 

programs on medium 3370, and study their functions. A ^he: attack technique might involve comparing the 

This analysis is represented in FIG. 67A by block 55 memory ^d/ov disk images of installed operational material 

3352C, producing source code 3371, 3472 soft war e and data files in a single instance of PPE 650, 

An attacker can use software reverse-engineering tools to after performing various operations using the PPE. This 

create an equivalent program to the programs stored on cou id serve to identify important data structures, such as 

medium 3370. As the equivalent program may be in a cryptographic keys (see "compare" block 3362A of FIG. 

more convenient form, possibly in a higher-level 60 67A; and FIG. 67B, block 3362). The resulting list of 

language, it may be more amenable to analysis. This differences 3362B could be carefully analyzed (see FIG. 

analysis is also represented in FIG. 67A by block 67A's magnifying glass 3362C) to obtain important clues, 

3352C, producing source code 3371. using analysis techniques such as described above. 

An attacker can use software debugging and/or simulation A further attack technique might involve analyzing the 

tools to follow and/or modify the dynamic execution of 65 timing and/or order of modification to memory and/or disk 

programs from medium 3370. This technique can be images of installed operational material 3472 software and 

combined with any of the above static analysis tech- data files in a single instance of PPE 650, during the 
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performance performing various operations using the PPE. 
This could serve to identify important data structures, such 
as cryptographic keys (see "compare" block 3362A of FIG. 
67A; and FIG. 67B, block 3362). The resulting list of 
differences 3362B could be carefully analyzed (see FIG. 5 
67A's magnifying glass 3362C) to obtain important clues, 
using analysis techniques such as described above. 

A further attack technique might involve duplicating one 
installed operational material 3472 instance by copying the 
programs and data from one personal computer 3372B to 10 
another personal computer 3372C or emulator (see FIG. 
67B, block 3364, and the "copy" arrow 3364A in FIG. 67A). 
The duplicated PPE instance could be used in a variety of 
ways, such as, for example, to place an impostor PPE 650 
instance on-line and/or to permit further dynamic analysis. 15 

A still additional avenue of attack might involve, for 
example, saving the state of a PPE 650 (see FIG. 67 A, block 
3366B) — for example, before the expenditure of credit — 
and restoring the state at a subsequent time (e.g., after a 
payment operation occurs) (see FIG. 67A, arrows 336 6 A, 20 
3366C, and FIG. 67B, block 3366). The stored state infor- 
mation 3366B may also be analyzed (see FIG. 67A, mag- 
nifying glass 3354F. 

No software-only tamper resistant barrier 674 can be 
wholly effective against all of these threats. A sufficiently 25 
powerful dynamic analysis (such as one employing an 
in- circuit emulator) can lay bare all of the software-based 
PPE 650's secrets. Nonetheless, various techniques 
described below in connection with FIG. 69A and following 
make such an analysis extremely frustrating and time 30 
consuming — increasing the "work factor*' to a point where 
it may become commercially unfeasible to attempt to 
"crack" a software-based tamper resistant barrier 674. 

PPE Initialization ^ 

Each PPE 650 needs to be initialized before it can be used. 
Initialization may occur at the manufacturer site, after the 
PPE 650 has been placed out in the field, or both. The 
manufacturing process for PPE 650 typically involves 
embedding within the PPE sufficient software that will allow 40 
the device to be more completely initialized at a later time. 
This manufacturing process may include, for example, test- 
ing the bootstrap loader and challenge -response software 
permanently stored within PPE 650, and loading the PPE's 
unique ID. These steps provide a basic VDE-capable PPE 45 
650 that may be further initialized (e.g., after it has been 
installed within an electronic appliance 600 and placed in 
the field). In some cases, the manufacturing and further 
initialization processes may be combined to produce "VDE 
ready" PPEs 650. This description elaborates on the sum- 50 
mary presented above with respect to FIGS. 64 and 65. 

FIG. 68 shows an example of steps that may be performed 
in accordance with one preferred embodiment to initialize a 
PPE 650. Some of the steps shown in this flowchart may be 
performed at the manufacturing site, and some may be 55 
performed remotely through contact between a VDE admin- 
istrator and the PPE 650. Alternatively, all of the steps 
shown in the diagram may be performed at the manufactur- 
ing site, or all of the steps shown may be performed through 
remote communications between the PPE 500 and a VDE eo 
administrator. 

If the initialization process 1370 is being performed at the 
manufacturer, PPE 650 may first be attached to a testbed. 
The manufacturing testbed may first reset the PPE 650 (e.g., 
with a power on clear) (Block 1372). If this reset is being 65 
performed at the manufacturer, then the PPE 650 preferably 
executes a special testbed bootstrap code that completely 
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tests the PPE operation from a software standpoint and fails 
if something is wrong with the PPE. A secure communica- 
tions exchange may then be established between the manu- 
facturing testbed and the PPE 650 using an initial challenge- 
response interaction (Block 1374) that is preferably 
provided as part of the testbed bootstrap process. Once this 
secure communications has been established, the PPE 650 
may report the results of the bootstrap tests it has performed 
to the manufacturing testbed. Assuming the PPE 650 has 
tested successfully, the manufacturing testbed may down- 
load new code into the PPE 650 to update its internal 
bootstrap code (Block 1376) so that it does not go through 
the testbed bootstrap process upon subsequent resets (Block 
1376). The manufacturing testbed may then load new firm- 
ware into the PPE internal non-volatile memory in order to 
provide additional standard and/or customized capabilities 
(Block 1378). For example, the manufacturing testbed may 
preload PPE 650 with the load modules appropriate for the 
particular manufacturing lot. This step permits the PPE 500 
to be customized at the factory for specific applications. 

The manufacturing testbed may next load a unique device 
ID into PPE 650 (Block 1380). PPE 650 now carries a 
unique ID that can be used for further interactions. 

Blocks 1372-1380R typically are, in the preferred 
embodiment, performed at the manufacturing site. Blocks 
1374 and 1382-1388 may be performed either at the manu- 
facturing site, after the PPE 650 has been deployed, or both. 

To further initialize PPE 650, once a secure communica- 
tions has been established between the PPE and the manu- 
facturing testbed or a VDE administrator (Block 1374), any 
required keys, tags or certificates are loaded into PPE 650 
(Block 1382). For example, the manufacturing test bed may 
load its information into PPE 650 so the PPE may be 
initialized at a later time. Some of these values may be 
generated internally within PPE 650. The manufacturing 
testbed or VDE administrator may then initialize the PPE 
real time clock 528 to the current real time value (Block 
1384). This provides a time and date reference for the PPE 
650. The manufacturing testbed or the VDE administrator 
may next initialize the summary values maintained inter- 
nally to the PPE 500 (Block 138(f). If the PPE 650 is already 
installed as part of an electronic appliance 600, the PPE may 
at this point initialize its secure database 610 (Block 1388). 

FIG. 69 shows an example of program control steps 
performed by PPE 650 as part of a firmware download 
process (See FIG. 68, Block 1378). The PPE download 
process is used to load externally provided firmware and/or 
data elements into the PPE. Firmware loads may take two 
forms: permanent loads for software that remains resident in 
the PPE 650; and transient loads for software that is being 
loaded for execution. A related process for storing into the 
secure database 610 is performed for elements that have 
been sent to a VDE electronic appliance 600. 

PPE 650 automatically performs several checks to ensure 
that firmware being downloaded into the PPE has not been 
tampered with, replaced, or substituted before it was loaded. 
The download routine 1390 shown in the figure illustrates an 
example of such checks. Once the PPE 650 has received a 
new firmware item (Block 1392), it may check the item to 
ensure that it decrypts properly using the predetermined 
download or administrative object key (depending on the 
source of the element) (decision Block 1394), If the firm- 
ware decrypts properly ("yes" exits to decision Block 1394), 
the firmware as check valve may be calculated and com- 
pared against the check valve stored under the encryption 
wrapper of the firmware (decision Block 1396). If the two 
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check summed values compare favorably ("yes" exit to 
decision Block 1396), then the PPE 650 may compare the 
public and private header identification tags associated with 
the firmware to ensure that the proper firmware was pro- 
vided and had not been substituted (step not shown in the 
figure). Assuming this test also passes, the PPE 500 may 
calculate the digital signatures of the firmware (assuming 
digital signatures are supported by the PPE 650 and the 
firmware is "signed") and may check the calculated signa- 
ture to ensure that it compares favorably to the digital 
signatures under the firmware encryption wrapper (Blocks 
1398, 1400). If any of these tests fail, then the download will 
be aborted ("fail" termination 1401). 

Assuming all of the tests described above pass, then PPE 
650 determines whether the firmware is to be stored within 
the PPE (e.g., an internal non-volatile memory), or whether 
it is to be stored in the secure database 610 (decision Block 
1402). If the firmware is to be stored within the PPE ("yes" 
exit to decision Block 1402), then the PPE 500 may simply 
store the information internally (Block 1404). If the firm- 
ware is to be stored within the secure database 610 ("no" exit 
to decision Block 1402), then the firmware may be tagged 
with a unique PPE-specific tag designed to prevent record 
substitution (Block 1406), and the firmware may then be 
encrypted using the appropriate secure database key and 
released to the secure database 610 (Block 1408). 

Example Techniques for Forming Software-Based 
Tamper Resistant Barrier 

Various software protection techniques detailed above in 
connection with FIG. 10 may provide software-based 
tamper resistant barrier 674 within a software-only and/or 
hybrid software/hardware protected processing environment 
650. The following is an elaboration on those above- 
described techniques. These software protection techniques 
may provide, for example, the following: 

An on-line registration process that results in the creation 
of a shared secret between the registry and the PPE 650 
instance — used by the registry to create content and 
transactions that are meaningful only to that specific 
PPE instance. 

An installation program (that may be distinct from the 
PPE operational material software) that creates a cus- 
tomized installation of the PPE software unique to each 
PPE instance and/or associated electronic appliance 
600. 

Camouflage protections that make it difficult to reverse 
engineer the PPE 650 operational materials during PPE 
operation. 

Integrity checks performed during PPE 650 operation 
(e.g., during on-line interactions with trusted servers) to 
detect compromise and minimize damage associated 
with any compromise. 
In general, the software -based tamper resistant barrier 674 
may establish "trust" primarily through uniqueness and 
complexity. In particular, uniqueness and customization 
complicate the ability of an attacker to: 

make multiple PPE instances with the same apparent 
identity; 

make it harder for an attacker to create a software program 
(s) that will defeat the tamper-resistant barrier 674 of 
multiple PPE instances; 

make it harder for the attacker to reverse engineer (e.g., 
based upon encryption so that normal debugging/ 
emulation and other software testing tools can't easily 
provide access); and 
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make it more difficult for an attacker to compare multiple 
PPE instances to determine differences between them. 
In addition, the overall software-based tamper resistant 
barrier 674 and associated PPE system is sufficiently com- 

5 plex so that it is difficult to tamper with a part of it without 
destroying other aspects of its functionality (i.e., a "defense 
in depth"). Camouflaging techniques complicate an attack- 
er's analysis through use of debugging/emulation or other 
software tools. For example, the PPE 650 may rewrite or 

10 overwrite memory locations immediately after using same to 
make their contents unavailable for scrutiny. Similarly, the 
PPE 650 operational software may use hardware and/or time 
dependent sequences to prevent emulation. Additionally, 
some of the PPE 650 environment code may be self- 

15 modifying. These and other techniques make it much harder 
to crack an individual PPE 650 instance, and more 
importantly — much harder to write a program that could be 
used to defeat security on multiple PPE instances. Because 
the legitimate owner/user of a particular PPE instance may 

20 be trying to attack the security of his own system, these 
techniques assume that individual instances may eventually 
be cracked and provide additional security and safeguards 
that prevent (or make it more difficult) for the attacker who 
has cracked one PPE instance to use that information 

25 successfully in cracking other PPE instances. Specifically, 
these security techniques make it unlikely that an attacker 
who has successfully cracked one or a small number of PPE 
instances can write a program capable of compromising the 
security of any arbitrary other PPE instance, for example. 

30 

Example Installation Process 

Briefly, the preferred example software-based PPE 650 
installation process provides the following security tech- 
niques: 

35 encrypted software distribution, 

installation customized on a unique instance and/or elec- 
tronic appliance basis, 

encrypted on-disk form, 
4 q installation tied to payment method, 

unique software and data layout, and 

identifiable copies. 

FIG. 69 A shows one example technique for distributing 
the PPE 650 software. In this example, the PPE 650 software 

45 is distributed as two separate parts and/or media: the instal- 
lation materials 3470, and the operational materials 3472. 
Installation materials 3470 may provide executable code and 
associated data structures for installing the operational mate- 
rials 3472 onto a personal computer hard disk 3376, for 

50 example (see FIG. 67A). The operational materials 3472 
may provide executable code and associated data structures 
for providing protected processing environment 650 and 
associated software -based tamper resistant barrier 674, 
In this example, installation materials 3470 and opera- 

55 tional materials 3472 are each encrypted by a "deliverable 
preparation" process 3474 to provide encrypted installation 
materials 3470E and encrypted operational materials 3472E 
(the encrypted portions are indicated in FIG. 69A, by 
cross-hatching). In this example, a small portion 3470C of 

60 the installation materials 3470 may be maintained in clear 
(unencrypted) form to provide an initial portion of the 
installation routine that may be executed without decryption. 
This plain text portion 3470C may, for example, provide an 
initial dialog, using an encrypted or other secure protocol 

65 with a trusted registry 3476 such as VDE administrator 2007» 
for example. This makes the distributed installation materi- 
als 3470 and operational materials 3472 meaningless and 
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unreadable to an attacker without additional information 
since the entire content (except for the initial dialog with the 
registry 3476) is unreadable. 

In this example, the "deliverable preparation" process 
3474 may encrypt the installation materials 3470 and opera- 
tional materials 3472 using one or more secret keys known 
to the registry 3476. Multiple versions of these installation 
materials 3470 and operational materials 3472 may be 
distributed using different, secret keys so that compromise of 
one key exposes only a subset of the software distribution to 
unwanted disclosure. The only non-encrypted part of the 
software distribution in plaintext is that portion 3470C of 
installation materials 3470 used to establish initial contact 
with the registry 3476. 

The registry 3476 maintains a copy of the corresponding 
decryption keys within a key generation and cataloging 
structure 3478. It provides these keys on demand during the 
registration process (e.g., using a secure key exchange 
protocol, for example) to only legitimate users authorized to 
set up a new protected processing environment 650. 

FIGS. 69B-69C show example steps that may be per- 
formed by a installation routine 3470 to install a protected 
processing environment 650. In this example, upon coupling 
the installation materials 3470 to an electronic appliance 600 
such as a personal computer 3372, the appliance begins 
executing the unencrypted installation materials portion 
3470C. This plain text portion 3470C controls appliance 600 
to contact registry 3476 and establish a registry dialog (FIG. 
69B, block 3470(1)). The appliance 600 and the registry 
3476 use a secure key exchange protocol to exchange 
installation keys so that the registry may deliver the appro- 
priate installation key to the appliance (FIG. 69B, block 
3470(2)). Using the provided installation key(s), the appli- 
ance 600 may decrypt and run additional portions of 
encrypted installation materials 3470E (FIG. 69B, block 
3470(3) and following). Based on this additional installation 
program execution, appliance 600 may decrypt and install 
encrypted operational materials 3472E (FIG. 69B, block 
3470(4)). 

Rather than simply installing the operational materials 
3472, in one example, installation materials 3470 makes the 
installation different for each PPE 650 instance. For 
example, the installation materials 3470 may customize the 
installation by: 

uniquely embedding important data into the installed 
software, 

uniquely encrypting the installed software, 
uniquely making random changes to the installed 
software, 

uniquely mating the installed software with a particular 

electronic appliance 600, 
providing a unique static and/or dynamic layout or other 

structure. 

Randomly Embedded Cryptographic Keys 

Installation routine 3470 may, for example, modify the 
operational materials 3472 to customize embedded locations 
where critical data such as cryptographic keys are stored. 
These keys may be embedded into the text of the operational 
materials 3472 at locations that vary with each installation. 
In this example, the registry 3476 may choose, on a random 
or pseudo -random basis, at least some of the operational 
material 3472 locations in which a particular installation 
routine 3470 may embed cryptographic keys or other critical 
data (see FIG. 69B, block 3470(5)). 

The installation process for the operational software may 
involve decrypting its distribution (which may be the same 
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for alt end users) and modifying it to encode the specific 
locations where its critical data (e.g., cryptographic keys) are 
stored. These keys may be embedded within the text of the 
program at locations that vary with every installation. The 

5 distribution of unique information into the operational soft- 
ware 3472 can be based on a secret key known to the registry 
3476. This key may be communicated by the registry 3476 
during the registration dialog using a secure key exchange. 
The key is shared between the registry 3476 and the PPE 650 

10 instance, and can serve both to organize the installed PPE 
software, and as the basis of subsequent integrity checks. 

As shown in FIG. 69D, the operational materials 3472 
may include embedded locations 3480(a), 3480(f)), 3480(c), 
3480(iQ, 3480(e), . . . reserved for storing (embedding) 

15 critical information such as cryptographic keys. Each of 
these locations 3480 may initially store a random number 
string. In one example, the registry 3476 or installation 
routine 3470 performs a random operation 3482 to randomly 
select which subset of these locations 3480 is to be used by 

20 a particular instance for storing critical data. This selection 
list 3484 is applied as an input to an operation materials 
preparation step 3474a (part of the deliverable preparation 
operation 3474 shown in FIG. 69A). The operation materials 
preparation step 3474a also accepts, as an input, crypto- 

25 graphic keys from a secure key store 3486. In this example, 
the operation materials preparation step 3474a embeds the 
cryptographic keys provided by key store 3486 into the 
selected locations 3484 of operation materials 3472. 
In accordance with one example, the random operation 

30 3482 selects a subset that is much less than all of the possible 
locations 3480 — and the locations 3480 not used for storing 
cryptographic keys store random data instead. An attacker 
attempting to analyze installed operational materials 3472 
won't be able to tell the difference between real crypto- 

35 graphic keys and random number strings inserted into a 
place where cryptographic keys might be stored. 

In this example, the random location selection 3484 
(which is unique for each installation) may itself be 

4Q encrypted by block 3488 based on an installation-unique key 
provided by key generation block 3490 for example. The 
encryption key may be securely maintained at registry 3476 
so that the registry may later notify the installation materials 
3470 of this key — allowing the installation materials to 

45 decrypt the resulting encrypted key location block 3492 and 
recover listing 3484 of the subset of locations 3480 used for 
embedding cryptographic keys. 

Embedded Customized Random Changes 

50 Referring once again to FIG. 69B, the installed opera- 
tional materials 3472 may be further customized for each 
instance by making random changes to reserved, unused 
portions of the operational materials (FIG. 69B, block 
3470(6)). An example of this is shown in FIG. 69E. In this 

55 example, the operational materials 3472 include unused, 
embedded random data or code portions 3494. Another 
technique with similar effect is shown in FIG. 69F. In this 
example, false code sections 3496 are included within 
reserved areas of the operational materials 3472. These false 

60 code sections 3496 add complexity, and may also be used as 
a electronic "fingerprint" to help trace copies. Because the 
false code sections 3496 are executable program code that 
are never executed (or if executed perform no actual func- 
tions other than confounding analysis by, for example, 

65 creating, modifying and/or destroying data that has no 
impacton the operation of PPE 650 but may appear to have 
such an impact), they can be used to confound analysis 
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because they may be difficult for an attacker to distinguish 
from true code sections. In addition other false code may 
have the effect of disabling the execution of PPE 650 if 
executed. Correspondence Between Installed Software and 
Appliance "Signature". Another technique that may be used 
during the installation routine 3470 is to customize the 
operational materials 3472 by embedding a "machine sig- 
nature" into the operational materials to establish a corre- 
spondence between the installed software on a particular 
electronic appliance 600 (FIG. 69C, block 3470(7)). This 
technique prevents a software-based PPE 650 from being 
transferred from one electronic appliance 600 to another 
(except through the use of the appropriate secure, verified 
backup mechanism). 

For electronic appliances 600 where it is feasible to do so, 
the installation procedure 3470 may determine unique infor- 
mation about the electronic appliance 600 (e.g., a "signa- 
ture" SIG in the sense of a unique value — not necessarily a 
"digital signature" in the cryptographic sense). Installation 
routine 3470 embeds the electronic appliance "signature" 
SIG in the installed operational materials 3472. Upon 
initialization, the operational materials 3472 validate the 
embedded signature value against the actual electronic 
appliance 600 signature SIG, and may refuse to start if the 
comparison fails. 

Depending on the configuration of electronic appliance 
600, the machine signature may consist, for example, of 
some combination of 

a hash of the ROM BIOS 658' (see FIG. 69G), 

a hash of a disk defect map 3497a, 

the Ethernet (or other) network adapter 666 address, 

information written into an unused disk sector, 

information stored in a non-volatile CMOS RAM(such as 
used for hardware configuration data), 

information stored in non -volatile ("flash") memory (such 
as used for system or peripheral component "BIOS" 
programs) and/or 

hidden unique information placed into the root directory 
34976 of the fixed disk drive 668. 

FIG. 69G shows an example of some of these appliance - 
specific signatures. 

In this example, machine signature information need not 
be particularly large. Security is provided by hiding the 
machine signature rather than on any other cryptographic 
strength, because there is no more secure mechanism for key 
storage to protect it. Thus, it is satisfactory for the signature 
to be just large enough (e.g., two bytes) that it is unlikely to 
be duplicated by chance. 

For some electronic appliances 600 where it can be 
determined that the technique is safe, an otherwise unused 
section of the non-volatile CMOS RAM 656a may be used 
to store a signature 3497o\ Signature 3497d is verified 
against the PPE 650's internal state whenever the PPE is 
initialized. Signature 3497a* may also be updated whenever 
a significant change is made to the secure database 610. If 
the CMOS RAM signature 34974 does not match the 
database value, PPE 650 may take this mismatch as an 
indication that a previous instance of the secure database 
610 and/or PPE 650 software has been restored, and appro- 
priate action can be taken. This mechanism thus ensures that 
even a bit-for-bit copy of the system's fixed disk 668 or other 
storage medium cannot be saved and reloaded to restore an 
earlier PPE 650 state. This particular technique depends 
upon there being an unused location available within CMOS 
RAM 656a, and may also require the CMOS RAM check- 
sum algorithm to be known. An incorrect implementation 
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could cause a subsequent reboot of electronic appliance 600 
to fail because of a bad CMOS checksum, or worse, could 
alter some critical configuration parameter within CMOS 
RAM 656a so that electronic appliance 600 could not be 
recovered. Thus, care must be taken before modifying the 
contents of CMOS RAM 656a. 

A still alternate technique may involve marking otherwise 
"good" disk sectors 3497c defective and using the sectors) 
to store machine signatures and/or encryption keys. This 
technique ensures that a logical bit-for-bit copy of the media 
does not result in a usable PPE 650 instance, and also 
provides relatively inaccessible and non-volatile storage for 
the information. Because a relatively large amount of stor- 
age space can be reserved using this technique, there is 
enough storage for a cryptographically strong value. 

Some of the "machine signature" techniques discussed 
above may be problematic in some electronic appliances 600 
because it may be difficult to locate appropriate appliance- 
unique information. For example, although in a personal 
computer a ROM BIOS 658' is always available, the ROM 
BIOS information by itself may be insufficient because it is 
likely to be identical for a batch of electronic appliances 600 
purchased together. Identifying a network adapter 666 and 
determining its address is potentially difficult due to the wide 
variety of adapters; additionally, an electronic appliance's 
network address may change (although this occurrence may 
be infrequent). Inserting random signature values into 
unused bytes within the fixed disk root directory 3497£> 
and/or partition records may trigger some virus-checking 
programs, and the data may be modified by defragmentation 
or other disk manipulation programs. Where supported, a 
truly unused disk sector 3497c (e.g., one that is marked 
"bad" even though it may still viably store information) may 
be used to store the machine signature. Even so, normal 
maintenance, upgrades or other failure recovery procedures 
may disrupt a particular machine association. Since the VDE 
administrator 200A participates in restoring a PPE 650 based 
on an encrypted backup image (as described above for 
example in connection with FIGS. 39-40), the VDE admin- 
istrator may establish new associations at this point to 
maintain correspondence between a particular PPE 650 
installation and a particular electronic appliance 600. 

Tie Installation to Payment Method 

A still additional example technique for providing addi- 
tional security is to tie a particular PPE 650 installation at 
registration time to a particular payment method (see FIG. 
69C, block 3470(8)). The registration process at installation 
time may thus serve to tie the PPE 650 installation to some 
payment method associated with the user, and to store the 
payment association information both within the PPE 650 
instance and at the registry 3476. This technique assures that 
the actions of a particular PPE 650 instance are accountable 
to the assigned user with at least the reliability of whatever 
payment/credit verification technique is employed. 

Install Operational Materials in Encrypted Form 
Operational materials 3472 may first be customized as 
described above for the particular instance and/or appliance 
600, then (at least mostly) encrypted for installation into the 
appliance such as by storage onto disk 668 (see FIG. 69C, 
block 3470(9)). Different installations may use different sets 
of decryption keys to decrypt the information once installed. 
Different parts of operational materials 3472 may be 
encrypted with different cryptographic keys to further com- 
plicate the analysis. This encryption makes analysis of the 
on disk form of the operational materials 3472 more difficult 
or infeasible. 
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The beginning of the resulting stored executable file may 
contain a small decryption program ("decryptor") that 
decrypts the remainder of the operational materials 3472 as 
they are loaded into memory. Confounding algorithms (as 
described below) may be used in this decryptor to make 
static recovery of the cryptographic keys difficult. Although 
the decryptor is necessarily in unencrypted form in an 
all-software installation without hardware support, the use 
of confounding algorithms to develop the associated cryp- 
tographic keys effectively requires a memory image to be 
captured after the program has been decrypted. Where 
supported (as described above), an unused and inaccessible 
disk sector 3497c may be used to store the decryption keys, 
and the operational materials 3472 may possess only the 
address for that particular sector. Embedding this address 
further complicates analysis. 

Customized Layout 



The installation materials 3470 may store the encrypted 
operational materials 3472 onto the fixed disk 668 using a 
customized storage layout (FIG. 69C, block 3470(10)). FIG. 
69F, 69H, 691 and 69 J shows example customized software 
and data layouts. In these examples, each installed instance 
of operational materials 3472 is different in both executable 
form and in data layout. These modifications make each PPE 
650 instance require separate analysis in order to determine 
the storage locations of its critical data such as cryptographic 
keys. This technique is an effective counter to creation of 
programs that can undo the protections of an arbitrary PPE 
650 instance. 

Instruction sequences within the operational materials 
3472 may be modified by the installation routine to change 
the execution flow of the executable operational materials 
3472 and to alter the locations at which the software expects 
to locate critical data. The alterations in program flow may 
include customization of time-consuming confounding algo- 
rithms. The locations of the modifiable instruction 
sequences may be embedded within operational materials 
3470, and may therefore be not directly available from an 
examination of the installation and/or operational materials. 

FIG. 69H shows one example operational materials 3472 
executable code segment provided distinct processes 3498a, 
34986, 3498c, 34984 3498e. In this particular example, 
segment 3498a is executed first and segment 3498e is 
executed last, but the processes 34986, 3498c and 3498d 
may be performed in any order (i.e., they are sequence 
independent processes). The installation materials 3470 may 
take advantage of this sequence independence by storing 
and/or executing them in different and/or depending upon 
the particular PPE instance 650. FIG. 691, for example, 
shows a first static layout order, and FIG. 69J shows a 
second, different static layout order. Data elements associ- 
ated with the execu tables may similarly be stored in different 
orders (as shown in FIGS. 691, 69J) depending upon the 
particular installation. 

Dynamic Protection Mechanisms 

In addition to the more static protection mechanisms 
described above, dynamic protection mechanisms may be 
employed to complicate both static and dynamic analysis of 
the executable (executing) operational materials 3472. Such 
techniques include, for example: 

implementation complexity, 

immediate overwriting, 

hardware dependent sequences, 
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timing dependencies, 
confounding algorithms, 
random modifications, 
dynamic load module decryption, 
on-line integrity checks, 
time integrity checks, 
machine association integrity checks, 
dynamic storage integrity checks, and 
hidden secret storage 
volatile secret storage 
internal consistency checks. 

FIGS. 69K-69L show an example execution of opera- 
tional materials 3472 that may employ some or all of these 
various dynamic protection mechanisms. 

Upon starting execution (FIG. 69K, block 3550), the 
installed operational materials 3472 may run initialization 
code as described above that is used to decrypt the stored 
encrypted operational materials on an "as needed" basis 
(FIG. 69K, block 3552). This initialization code may also 
check the current value of the real-time clock (FIG. 69K, 
block 3554). 

Real Time Check/Validation 
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Operational materials 3472 may perform this time check, 
for example, to guard against replay attacks and to ensure 
that the electronic appliance 600's time is in reasonable 
agreement with that of the VDE administrator 200/i or other 
trusted node. 

FIG. 69M shows an example sequence of steps that may 
be performed by the "check time" block 3554. In this 
example, PPE 650 uses secure communications (e.g. a 
cryptographic protocol) to obtain the current real time from 
a trusted server (FIG. 69M, block 3554a). PPE 650 may next 
ask the user if he or she wishes to reset the electronic 
appliance real-time clock 528 (which may, for example, be 
the real-time clock module within a personal computer or 
the like) so it is synchronized with the trusted server's time 
clock. 

If the user responds affirmatively, PPE 650 may reset the 
time clock to agree with the real-time provided by the trusted 
server ("yes" exit to decision block 3554^ FIG. 69M, block 
3554c). If the user responds that he or she does not want the 
real-time clock reset ("no" exit to decision block 3554ft), 
then PPE 650 may calculate a delta value of the difference 
between the server's real-time clock and the electronic 
appliance's real-time clock 528 (FIG. 69M, block 3554a). In 
either case, PPE 650 may store the current time Tcurrent into 
a non-volatile storage location Tstore indicating the current 
real-time (FIG. 69M, block 3554e). 

Referring again to FIG. 69K, PPE 650 can disable itself 
if there is too much (or the wrong type) of a difference 
between the trusted server's time and the electronic appli- 
ance's clock — since such differences can indicate replay 
attacks, the possibility that the PPE 650 has been restored 
based on a previous state, etc. For example, if desired, PPE 
650 can generate a time check fail exception if the electronic 
appliance's real-time clock 528 disagrees with the trusted 
server's real-time by more than a certain amount of accept- 
able drift (FIG. 69K, "yes" exit to decision block 3556). In 
the event of such an exception, PPE 650 may disable itself 
(FIG. 69K, block 3558) and require a dialog between the 
user and registry 3476 (or other authority)— providing addi- 
tional protection against replay attacks and also detecting 
clock failures that could lead to incorrect operation or 
incorrect charges. 
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Dynamic Code Decryption and Data Overwriting interval (FIG. 69K, block 3570, decision block 3572, "dis- 

_ . . * . , able" block 3574). An incorrect execution time suggests that 

Operational materials 3472 may then decrypt the next ^ ational materials M72 m bei externa lly manip u. 

program segment dynamically (FIG. 69K, block 3460. The lated &nal ^ or ^ u some manner ( b a 

code may be decrypted dynamically when it is needed, then $ software emu]ator) TOs techni ^ ovides 

re-encrypted or overwritten and discarded when not in use. otection aainst d ^ ^ ^ ui/m modificatio n. 

This mechanism increases the tamper- resistance of the . . . 

executable code— thus providing additional tamper resis- P* «pected execution intervals associated with certain 

tance for PPE operations. As mentioned above, different code f q«ences may be calculated during the installation 

decryption keys may be required to decode different code ln procedure Resulting test values may be embedded into the 

portions, and the decryption keys can be installation^pecific 10 "Phonal materials 3472. These timing tests may be 

so that an attacker who successfully comprises the decryp- ^grated with time mtegnty tests and dynamic integrity 

tion key of one instance cannot use that information to checks to mak f U more ^f* 11 * b yi»f them simply by 

compromise any other instance's decryption key(s). P atchm g ° u ' me , tmm S check - Care should be ,aken . to 

^ . ., ........ ehminate false alarms due to concurrent system activity 

Once . i portion , of ? the operational materials 3472 has been M ( Qther ^ 

decrypted (FIG. 69K, block 3560), that portion may imme- ° „ ^„„, , , ' 

diately overwrite all initialization code in memory since it is P' , 6 '* shows one example of a dynamic lime check 
no longer required (FIG. 69K, block 3562). The executing 3S70 : •» thiS «ample, a test may be performed to 
operational materials 3472 may similarly overwrite all fT e *1 ? T° * pe ?T Ume check 
unwrapped cryptographic keys once they are no longer 20 (decision block 3570a). For example, this test 3570a may be 
needed, and may also overwrite expanded key information Panned periodically and/or at the end of a trme-dependent 
developed by initializing the cryptographic algorithms once se 1 ucnce 35 Ascribed above. If performed periodically, a 
no longer needed. These techniques minimize the amount of cou ° ter V L . value mav . be cemented or reset to zero- 
time during which usable key information is available for ™AyW tba counter for the next performance of test3470A 
exposure a memory snapshot-complicating all but the v («• mG 69N « block 35 ™ b ' 3570c > 3570d ) 
most dynamic of analysis efforts. Because all keys in per- If it is time to perform a check, PPE 650 compares the 
manent storage are either encrypted or otherwise stored time value Tstore with the current time value 
camouflaged, no such treatment is required for I/O buffers. Tcurrent, and determines whether the two values are within 

an acceptable range (FIG. 69N, decision block 3570E). If the 

Dynamic Check of Association Between Appliance 30 two values agree within an acceptable range (this range may 

and PPE Instance be determined, for example, in part by the time-dependent 

_ . . . testing described above), then PPE 650 may replace the 

The executing operational materia s 3472 may next com- $tored ^ ^ TsU)re ^ ^ jGamjA m 

pare an embedded electronic appliance signature SIG* ration for lhe ncxt test 69N> block 3570F) [f on thc 

against the electronic apphance signature SIG stor ed in the Qther hand me {wQ ^ M ^ ^ 

electronic appliance itself (FIG. 69K, decision block 3564). * (the « QOt exit to decision block 3570E, FIG. 

As discussed above, this technique may be used to help 69N) ppE 650 dM ration (block 3570G) and 

prevent operational materials 3472 from operating on any initiate a convcrsatioil ^tf, a trusted time base or other 

electronic appliance 600 other than the one it was initially verification facility to perform further authenticity checking 

installed on PPE 650 may disable operation if this machine (FJG 69N> b]ock 35?0H) M mQ 69L ^ ^ 

signature check fails ( no exit to decision block 3564, FIG. 40 checks may be performed periodically and/or repeatedly 

69K; disable block 3566). based Qn omer events ^ blodc 358 ^ decision block 35g4j 

Self-Modifying and/or Hardware-Dependent Code disable block 3586). 

Sequences Confounding Algorithms 
Executing operational materials 3472 may also employ The executing operational materials 3472 may also per- 
self-modifying code sequences that cannot easily be emu- f or m various confounding algorithms — computationally 
lated with a software debugger or single-stepping program intensive algorithms that perform a complex operation in 
(FIG. 69K, block 3568). These sequences may, for example, or d er t 0 generate values required at run time (FIG. 69L, 
be dependent on specific models of electronic appliances 5Q block 3576). The purpose of such confounding algorithms is 
600, and may be patched into the operational materials 3472 t o make infrequendy invoked steps (e.g., initialization or 
as appropriate to installation materials 3470 based on tests other steps not performed very frequently) inscrutable to an 
performed during the installation process. Such hardware- attacker who is disassembling or tracing them. Confounding 
dependent sequences may be used to ensure that critical algorithms may also be used for the time-dependent check- 
algorithms yield different results when executed on the S5 m g described above. 

proper hardware as opposed to when executed on different Qne e le of such a "confounding algorithm" is a 

hardware or under software control such as ma debugger or modifled ye[sion of , he MD5 m e di t fmc&m 

emulator. To prevent such hardware-dependent sequences ( licd rcpeatedly to tbe ^ j„ put value), which tests 

from being .readily recognizable from a static examination of generated results of the round functions and 

the code, the sequences may be constructed at nin time and 6Q terminatcs when a cific vahie ^ cncount6re d. For 

then invoked so that they can be identified only by analysis exam fe one make rai)dom modiflcations to ^ «,„. 

of tbe instruction sequences actually executed. founding (for 6Xample> by adjusting me .< magic 

Dynamic Timin Checks constants" in MD5) until it terminates quickly enough to be 

useful with the desired value in some register. This adjust- 

Executing operational materials 3472 may also make 65 ment may be performed beforehand to yield a prior knowl- 

dynamic timing checks od various code sequences, and edge of modifications that can then be installed differently 

refuse to operate if they do not execute within the expected and to each PPE 650 instance. 
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As one specific example, a family of 256 customized 
confounding algorithms could be created, each defined by a 
single modification of the MD5 "magic constants" (or even 
the input data to MD5) so that the algorithm terminates with 
. any of 256 possible values in some register. Critical values 
can then be generated at run time by installing appropriate 
versions of the algorithm into the operational materials 3472 
and assembling the values a byte at a time. Confounding 
algorithms may be performed in a time-dependent value as 
described above; their execution times may be logged and 
checked by PPE 650, and the PPE 650 may disable operation 
if the confounding algorithms run too rapidly or slowly. 

Such confounding algorithms are generally infeasible to 
simulate by hand because they may require tens or hundreds 
of millions of instructions to complete. They are expensive 
to analyze at run time because single-stepping through the 
code is time consuming (though not prohibitive, particularly 
if break points are set at all the possible termination tests 
rather than for every instruction). Although such confound- 
ing algorithms are expensive in computation time, then need 
not be invoked frequently — preserving efficiency. 

Random Modifications to Environment State 

The executing operational materials 3472 may randomly 
modify the PPE 650 environment state during normal opera- 
tion to reflect both actual PPE 650 operations being per- 
formed and to include random modifications of data not 
significant to the operating PPE 650 (FIG. 69L, block 3578). 
Such techniques help ensure that snapshots of the secure 
database 610 and operational materials 3472 cannot readily 
be compared to identify significant values and objects. 

Such modifications may be based, for example, on actual 
random values derived from unpredictable hardware events 
such as disk I/O completion timing and keyboard timing. 
Such techniques make it infeasible to experiment with 
"minor" changes to the PPE 650 state even if the attacker 
can successfully bypass integrity checks that prevent dupli- 
cates from being made. 

Load Module Dynamic Decryption & Re- 
Encryption 

The executing operational materials 3472 may decrypt 
load module 1100 code dynamically as needed, and 
re-encrypt it or otherwise render it inscrutable when not in 
use (FIG. 69L, block 3580). In accordance with this 
technique, load module executable code and/or data is 
decrypted dynamically when it is needed, then re-encrypted 
or destroyed when not in use. In addition, the location of 
executing load modules 1100 may be varied randomly to foil 
attempts to set break points within the load module. Differ- 
ent algorithms and a changing key may be used to further 
confound dynamic analysis. 

Hidden Secret Storage 

The source database 610 and/or parts or all of operational 
materials 3472 may be protected by cryptography employ- 
ing keys and/or authentication values hidden in normally 
inaccessible locations in the appliance 600. If the key or 
authentication value is not available, the decryption cannot 
be performed, rendering PPE 650 unusable. Examples of 
such locations include, but are not limited to: 

Disk storage artificially marked as damaged (for the 
purpose of storing secrets); 

Disk storage normally reserved as alternates for sectors 
that may be marked as damaged; 
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Disk storage normally reserved for non-general purpose 
use, such as sectors reserved by the manufacturer for 
firmware storage, for storage of statistics, or for test 
purposes, etc.; 

s Non-volatile, writable, storage in the appliance or its 
components, such as that used for configuration data, 
device and controlled firmware, standard BIOS 
software, etc; 

Unused storage in files maintained by an operating 
10 system, such as the bytes between the logical end of a 
file and the end of its last physical sector, etc.; 
Unused storage in file system control structures, such as 
the bytes available to store as-yet-undefined attributes, 
15 unused storage in file allocation maps and other 
structures, unused storage in redundant (duplicate) file 
maps and directories, unused or unneeded bytes in boot 
records, etc.; 

Storing secrets (e.g., cryptographic keys and authentica- 
2Q tion values) in these locations serves two purposes: it makes 
them difficult to locate by analysis of the PPE 650, and it 
makes them difficult to copy between one instance of the 
PPE and another (or to replace the PPE's contents with an 
earlier version of the same). 

25 Volatile Secret Storage 

The secure database 610 and/or parts or all of operational 
materials 3472 may be protected by cryptography employ- 
ing keys and/or authentication values ("cryptovariables") 
3 q that are maintained only in volatile storage during normal 
operation. For example, during an initialization sequence, 
cryptovariables can be read from permanent storage (e.g., 
disk), overwritten, and held only in volatile memory during 
system operation. During the shutdown sequence, the cryp- 
35 tovariables can be rewritten to permanent storage. 

This provides resistance to tampering because the initial- 
ization sequence for an appliance, particularly a general- 
purpose computer, is typically more difficult to tamper with 
than is the computer during normal operation. This tech- 
40 nique prevents the computer from itself being used to 
analyze the contents of permanent storage media; only by 
removing the media and analyzing it independently can the 
cryptovariables be located and extracted. This technique has 
the drawback of requiring the appliance's operation always 
45 to be terminated normally so that the termination sequence 
is guaranteed to update the permanent storage. This draw- 
back can be ameliorated by maintaining frequent backups of 
the secure database 610 and/or the protected crypto- 
variables that can be restored with administration by VDE 
50 administrator 200/z if a disorderly termination occurs. 

Dynamic Integrity Checks 

In this example, operational materials 3472 may also 
perform a variety of dynamic integrity checks that tie an 

55 executing PPE 650 to a particular electronic appliance 600 
and to guard against various forms of replay or substitution 
attacks. One example of a replay attack, for example, is an 
attack in which a user restores the PPE 650 state from an 
earlier backup — wiping out all recent billing records. PPE 

60 650 includes a backup mechanism (as discussed above in 
connection with FIGS. 39 and 40) that supports restoration 
of previous states after system failure. Executing operational 
materials 3472 in this example provides certain dynamic 
protection mechanisms (integrity checks) that prevent such 

65 backup and restoration processes from being misused to 
allow such replay attacks. Such checks may identify incom- 
plete or erroneous attempts to subvert tamper resistant 
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barrier 672. Great care must be taken to ensure that these keys are, in principal, readily available in memory (e.g., 

checks do not trigger as a result of execution or implemen- because after all, the PPE 650 must be able to get them), 

tation error, as there is potential for significant disruption. there may be many keys and it will be difficult to identify the 

For example, during PPE 650 operation, the internal state right one rapidly. In addition, a primary benefit to be sought 

of the PPE is constantly being updated. During each inter- 5 DV subverting protection of software-based PPE 650 instal- 

action with a trusted server, PPE 650 (and the trusted server) la"°n s is & c abilit y to acquire content without paying for 

may test the internal state of PPE 650 to determine whether il — in other words > the abilit Y to " CTeate money". The 

it could be derived from the internal state last seen by the integrity checks discussed above mean that any error in 

trusted server for this particular PPE 650 instance. If it could manipulating the budget and usage information data is likely 

not, the result may be taken as indicating a replay attack of 10 to DC detected quickly. Even if the checks occur off-line 

some sort, and an appropriate action can be taken (see FIG. without notification to any trusted server, it will make the 

69L> block 3592, 3594, 3596). user's PPE 650 instance effectively useless — requiring its 

For example, such a check could be implemented using a destruction and recreation, 

counter stored in PPE 650 and updated every time an Networking SPUs 500 and/or VDE Electronic 

operation is performed. If the trusted server finds the counter Appliances 600 
to be smaller than at the previous server interaction, this 

finding is strong evidence that a previous state of the PPE In the context of many computers interconnected by a 

650 environment has been restored. In practice, the check local or wide area network, it would be possible for one or 

might be implemented with an obscure technique to prevent a few of them to be VDE electronic appliances 600. For 

easy manipulation of the counter value. For example, the 20 example, a VDE-capable server might include one or more 

counter could be repeated hashing (e.g., with MD5) of a SPUs 500. This centralized VDE server could provide all 

value that is stored redundantly in several different locations VDE services required within the network or it can share 

within the operational materials 3472 and secure database VDE service with VDE server nodes; that is, it can perform 

610 — so that the trusted server could verify that the current a few, some, or most VDE service activities. For example, 

value can be derived (e.g., by repeated MD5 applications) 25 a user's non-VDE computer could issue a request over the 

from a previous value. Such checks may limit the severity of network for VDE-protected content. In response to the 

loss resulting from off-line manipulation of PPE 650. request, the VDE server could comply by accessing the 

Because the trusted server verifies the consistency of PPE appropriate VDE object 300, releasing the requested content 

650 at each interaction, the only loss that may occur as a and delivering the content over the network 672 to the 

result of wholesale reloading of an earlier PPE 650 state is 30 requesting user. Such an arrangement would allow VDE 

that of content that has already been delivered by has not yet capabilities to be easily integrated into existing networks 

been charged for. without requiring modification or replacement of the various 

One example of a dynamic integrity check that executing computers and other devices connected to the networks, 

operational materials 3472 may perform (FIG. 69 L, block 3S For example, a VDE server having one or more protected 

3588) might, for example, be the periodic verification of the processing environments 650 could communicate over a 

integrity of the operational materials code in memory by a network with workstations that do not have a protected 

checksum invoked by a timer. If the timer does not tick processing environment. The VDE server could perform all 

regularly, the PPE 650 may detect it and cease to operate secure VDE processing, and release resulting content and 

(see FIG. 69N). This verification may counter attacks that 4Q other information to the workstations on the network. This 

might, for example, attempt to trick PPE 650 access methods arrangement would require no hardware or software modi- 

into releasing content that has been decrypted but not fixation to the workstations. 

electronically fingerprinted. Executing operational materials However, some applications may require greater security, 
3472 may also include numerous internal consistency flexibility and/or performance that may be obtained by 
checks to prevent substitution (replay) of stale database 6 10 45 providing multiple VDE electronic appliances 600 con- 
records, introduction of invalid load modules 1100, external nected to the same network 672. Because commonly -used 
modification of the secure database 610, and so on. Such local area networks constitute an insecure channel that may 
checks may be made sufficiently complex and interwoven as be subject to tampering and/or eavesdropping, it is desirable 
to make modifications likely to be detected. in most secure applications to protect the information com- 

When an inconsistency is detected ("yes" exit to decision 50 municated across the network. It would be possible to use 

block 3590, FIG. 69L), PPE 650 can take appropriate action conventional network security techniques to protect VDE- 

such as locking itself up from further use until reconstructed released content or other VDE information communicated 

under the trusted server's control (FIG. 69L, disable block across a network 672 between a VDE electronic appliance 

3591). For example, PPE 650 could encrypt iis secure 600 and a non-VDE electronic appliance. However, advan- 

database 610 with a new, random key, then encrypt that with 55 tages are obtained by providing multiple networked VDE 

the server's public key. Only the server could then arrange electronic appliances 600 within the same system, 

to reconstruct the user's instance of PPE 650. As discussed above in connection with FIG. 8, multiple 

VDE electronic appliances 600 may communicate with one 

Defense in Depth another over a network 672 or other communications path. 

Finally, although not a "camouflage" technique perse, the 60 Such networking of VDE electronic appliances 600 can 

complexity of operational materials 3472 may make it provide advantages. Advantages include, for example, the 

difficult to understand them from the outside in. As dis- possibility of centralizing VDE resources, storing and/or 

cussed above, PPE 650 may make extensive use of RPC and archiving metering information on a server VDE and deliv- 

coordinated work in different threads of execution. Because ering information and services efficiently across the network 

much of the RPC traffic may be encrypted, it will be difficult 65 672 to multiple electronic appliances 600. 

to unravel even if operational materials 3472 are heavily For example, in a local area network topology, a "VDE 

instrumented by the attacker. Although the cryptographic server" electronic appliance 600 could store VDE-protected 
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information and make it available to one or more additional appliance 600 having a SPU 500, VDE-protected informa- 

electronic appliances 600 or computers that may communi- tion may be securely sent to the peripheral across the 

cate with the server over network 672. As one example, an insecure channel for processing (e.g., decryption) at the 

object repository 728 storing VDE objects could be main- peripheral device. Giving the peripheral device the capabil- 

tained at the centralized server, and each of many networked 5 ity of handling VDE-protected information directly also 

electronic appliance 600 users could access the centralized increases flexibility. For example, the VDE electronic appli- 

object repository over the network 672 as needed. When a ance 600 peripheral device may control VDE object 300 

user needs to access a particular VDE object 300, her usage. It may, for example, meter the usage or other param- 

electronic appliance 600 could issue a request over network eters associated with the information it processes, and it may 

672 to obtain a copy of the object. The "VDE server" could 1Q gather audit trials and other information specific to the 

deliver all or a portion of the requested object 300 in processing it performs in order to provide greater informa- 

response to the request. Providing such a centralized object tion gathering about VDE object usage. Providing multiple 

repository 728 would have the advantage of minimizing cooperating VDE electronic appliances 600 may also 

mass storage requirements local to each electronic appliance increase performance by eliminating the need to move 

600 connected to the network 672, eliminate redundant encrypted information to a VDE electronic appliance 600 

copies of the same information, ease information manage- , and then move it again in unencrypted form to a non-VDE 

ment burdens, provide additional physical and/or other device. The VDE-protected information can be moved 

security for particularly important VDE processes and/or directly to its destination device which, if VDE-capable, 

information occurring at the server, where providing such may directly process it without requiring involvement by 

security at VDE nodes may be commercially impractical for 2Q some other VDE electronic appliance 600. 

certain business models, etc. FIG. 70 shows an example of an arrangement 2630 

It may also be desirable to centralize secure database 610 comprising multiple VDE electronic appliances 600(1), 600 

in a local area network topology. For example, in the context (2), 600(3), . . . , 600(N), VDE electronic appliances 

of a local area network, a secure database 610 server could 600(1) . . . 600(N) may communicate with one another over 

be provided at a centralized location. Each of several elec- 25 a communications path 2631 (e.g., the system bus of a work 

tronic appliances 600 connected to a local area network 672 station, a telephone or other wire, a cable, a backplane, a 

could issue requests for secure database 610 records over the network 672, or any other communications mechanism), 

network, and receive those records via the network. The Each of the electronic appliances 600 shown in the figure 

records could be provided over the network in encrypted ma y have the same general architecture shown in FIG. 8, 

form. "Keys" needed to decrypt the records could be shared 30 i.e., they may each include a CPU (or microcontroller) 654, 

by transmitting them across the network in secure commu- SPU 500, RAM 656, ROM 658, and system bus 653. Each 

nication exchanges. Centralizing secure database 610 in a of the electronic appliances 600 shown in the figure may 

network 672 has potential advantages of minimizing or have an interface/controller 2 632 (which may be considered 

eliminating secondary storage and/or other memory require- to be a particular kind of I/O controller 660 and/or commu- 

ments for each of the networked electronic appliances 600, 35 nications controller 666 shown in FIG, 8). This interface/ 

avoiding redundant information storage, allowing central- controller 2632 provides an interface between the electronic 

ized backup services to be provided, easing information appliance system bus 653 and an appropriate electrical 

management burdens, etc. connector 2634. Electrical connectors 2634 of each of the 

One way to inexpensively and conveniently deploy mul- respective electronic appliances 600(1), . . . 600(N) provide 

tiple instances of VDE electronic appliances 600 across a 40 a connection to a common network 672 or other communi- 

network would be to provide network workstations with cation paths. 

software defining an HPE 655. This arrangement requires no Although each of electronic appliances 600 shown in the 

hardware modification of the workstations; an HPE 655 can figure may have a generally similar architecture, they may 

be defined using software only. An SPE(s) 503 and/or perform different specialized tasks. For example, electronic 

HPE(s) 655 could also be provided within a VDE server. 4S appliance 600(1) might comprise a central processing sec- 

This arrangement has the advantage of allowing distributed tion of a workstation responsible for managing the overall 

VDE network processing without requiring workstations to operation of the workstation and providing computation 

be customized or modified (except for loading a new resources. Electronic appliance 600(2) might be a mass 

program(s) into them). VDE functions requiring high levels storage device 620 for the same workstation, and could 

of security may be restricted to an SPU-based VDE server. 50 provide a storage mechanism 2636 that might, for example, 

"Secure" HPE-based workstations could perform VDE func- read information from and write information to a secondary 

tions requiring less security, and could also coordinate their storage device 652. Electronic appliance 600(3) might be a 

activities with the VDE server. display device 614 responsible for performing display tasks, 

Thus, it may be advantageous to provide multiple VDE and could provide a displaying mechanism 2638 such as a 

electronic appliances 600 within the same network. It may 55 graphics controller and associated video or other display, 

also be advantageous to provide multiple VDE electronic Electronic appliance 600(N) might be a printer 622 that 

appliances 600 within the same workstation or other elec- performs printing related tasks and could include, for 

tronic appliance 600. For example, an electronic appliance example, a print mechanism 2640. 

600 may include multiple electronic appliances 600 each of Each of electronic appliances 600(1), . . . 600(N) could 

which have a SPU 500 and are capable of performing VDE eo comprise a different module of the same workstation device 

functions. all contained within a common housing, or the different 

For example, one or more VDE electronic appliances 600 electronic appliances could be located within different sys- 

can be used as input/output device(s) of a computer system. tern components. For example, electronic appliance 600(2) 

This may eliminate the need to decrypt information in one could be disposed within a disk controller unit, electronic 

device and then move it in unencrypted form across some 65 appliance 600(3) could be disposed within a display device 

bus or other unsecured channel to another device such as a 614 housing, and the electronic appliance 600(N) could be 

peripheral. If the peripheral device itself is a VDE electronic disposed within the housing of a printer 622. Referring back 
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to FIG. 7, scanner 626, modem 61K, telecommunication 500(N) to use the decryption key and associated limit to 
means 624, keyboard 612 and/or voice recognition box 613 process any following encrypted print stream (or this com- 
could each comprise a VDE electronic appliance 600 having mand could be sent by CPU 654(1) to microcontroller 
its own SPU 500. Additional examples include RF or 654(N)). Electronic appliance 600(1) could then begin send- 
otherwise wireless interface controller, a serial interface 5 ing encrypted information on path 672 for decryption and 
controller, LAN controllers, MPEG (video) controllers, etc. printing by printer 622. Upon receipt of each new block of 
Because electronic appliances 600(1) . . . 600(N) are each information by printer 622, SPU 500(N) might first check to 
VDE-capable, they each have the ability to perform encryp- ensure that the limit is greater than zero. SPU 500(N) could 
tion and/or decryption of VDE-protected information. This then increment a usage meter value it maintains, and dec- 
means that information communicated across network 672 10 rement the limit value. If the limit value is non-zero, SPU 
or other communications path 2631 connecting the elec- 500(N) could decrypt the information it has received and 
tronic appliances can be VDE-protected (e.g., it may be provide it to print mechanism 2640 for printing. If the limit 
packaged in the form of VDE administrative and/or content is zero, then SPU 500(N) would not send the received 
objects and encrypted as discussed above). One of the information to the print mechanism 2640, nor would it 
consequences of this arrangement is that an eavesdropper 15 decrypt it. Upon receipt of a command to stop, printer 622 
who taps into communications path 2631 will not be able could revert to a "non-secure" mode in which it would print 
obtain information except in VDE-protected form. For everything received by it across path 2631 without permit- 
example, information generated by electronic appliance ting VDE processing. 

600(1) to be printed could be packaged in a VDE content The SPU 500(N) associated with printer 622 need not 
object 300 and transmitted over path 2631 to electronic 20 necessarily be disposed within the housing of the printer, but 
appliance 600(N) for printing. An attacker would gain little could instead be placed within an I/O controller 660 for 
benefit from intercepting this information since it is trans- example (see FIG. 8). This would allow at least some of the 
mitted in protected form; she would have to compromise advantages similar to the ones discussed above to be pro- 
electronic appliance 600(1) or 600(N) (or the SPU 500(1), vided without requiring a special VDE^apable printer 622. 
500(N)) in order to access this information in unprotected M Alternatively, a SPU 500(N) could be provided both within 
form. printer 622 and within I/O controller 660 communicating 

Another advantage provided by the arrangement shown in with the printer to provide advantages in terms of coordi- 
the diagram is that each of electronic appliances nating I/O control and relieving processing burdens from the 
600(1), . . . 600(N) may perform their own metering, control SPU 500 associated with the central processing electronic 
and/or other VDE-related functions. For example, electronic 30 appliance 600(1). When multiple VDE instances occur 
appliance 600(N) may meter and/or perform any other VDE within an electronic appliance, one or more VDE secure 
control functions related to the information to be printed, subsystems may be "central" subsystems, that is "second- 
electronic appliance 600(3) may meter and/or perform any ary" VDE instances may pass encrypted usage related infor- 
other VDE control functions related 10 the information to be mation to one or more central secure subsystems so as to 
displayed, electronic appliance 600(2) may meter and/or 35 allow said central subsystem to directly control storage of 
perform any other VDE control functions related to the said usage related information. Certain control information 
information to be stored and/or retrieved from mass storage may also be centrally stored by a central subsystem and all 
620, and electronic appliance 600(1) may meter and/or or a portion of such information may be securely provided 
perform any other VDE control functions related to the to the secondary secure subsystem upon its secure VDE 
information it processes. 40 request. 

In one specific arrangement, each of electronic appliances Such printer protections as described above may be 

600(1), . . . 600(N) would receive a command that indicates particularly useful, for example, in the case of content 

that the information received by or sent to the electronic providers that want to restrict or otherwise control (e.g., 

appliance is to use its SPU 500 to process the information to charge for) printing of their content. These controls can be 

follow. For example, electronic appliance 60U(N) might 45 easily enforced in the case of printers as described above 

receive a command that indicates that information it is about having SPUs 500 (PPEs 650), but may be difficult to enforce 

to receive for printing is in VDE-protected form (or the in the case of general-purpose printers that do not have an 

information that is sent to it may itself indicate this). Upon SPU (PPE). It may be relatively easy in such environments 

receiving this command or other information, electronic to use printer redirectors, print output to a file, or otherwise 

appliance 600(N) may decrypt the received information 50 manipulate the system's printing functions. It therefore may 

using SPU 500, and might also meter the information the be advantageous to provide a strategy that protects printed 

SPU provides to the print mechanism 2644 for printing. An outputs in such general purpose printing environments, 

additional command might be sent to electronic appliance So-called "intelligent" printers are capable of executing 

600(N) to disable the decryption process or 600(N)'s VDE "scripts" or other programs comprising executable instruc- 

sccure subsystem may determine that the information should 55 tions or commands. Such "script" languages can be used to 

not be decrypted and/or printed. Additional commands, for provide a degree of tamper-resistance and security without 

example, may exist to load encryption/decryption keys, load the necessity of an SPU 500 (PPE 650). 

"limits," establish "fingerprinting" requirements, and read For example, it is possible to create a decryption program 

metered usage. These additional commands may be sent in 3900, in 

encrypted or unencrypted form as appropriate. <so PostScript or another printer control language, that can be 

Suppose, for example, that electronic appliance 600(1) downloaded 

produces information it wishes to have printed by a VDE- 3801 to an associated printer 3901, creating a program 3904 

capable printer 622, SPU 500(1) could establish a secure stored inside 

communications across path 2631 with SPU 500(N) to the memory of printer 3901. Because PostScript, as well as 

provide a command instructing SPU 500(N) to decrypt the 65 other similar 

next block of data and store it as a decryption key and a limit. printer control languages, is a general -purpose programming 

SPU 500(1) might then send a further command to SPU language, 
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such a program could decrypt (3802) an encrypted data printers incorporating non-executable control languages, by 

stream 3902 sent to downloading multiple fonts 3910a-2 incorporating different 

such a printer 3901. This approach would allow a local PPE images for characters. 
650 to 

prepare (3800) files for printing inside the PPE by creating 5 Portable Electronic Appliance 

£ , a S ft e ^ CryP L ted . « jit* * ' ^ ... Electronic appliance 600 provided by the present inven- 

file .3902 to be printed and delivering it for processing by the (ion be We nG n shows Qne e le of a 

decryption program inside the printer b]c electrQQic - 

iance 2600. Portable appliance 2600 

The decryption program 3900 could be downloaded r . . , . u, . • ~ £M 4 . . rf L , ( , 

(3801} as a printer ma ^ inc ^ u " e a P ortaD le housuig 2602 that may be about the 

initialization activity. Using features of the PostScript or 10 size of a cre ? il card | n one example Housing 2602 may 

other language, and/or other mechanisms in the printer, connect t0 the outsldc world throu S h > for example, an 

the decryption program electrical connector 2604 having one or more electrical 

3904 could be locked into the memory 3901m of printer contact pins (not shown). Connector 2604 may electrically 

3901 so it could not be connect an external bus interface 2606 internal to housing 

viewed and/or modified except with appropriate authoriza- 15 2602 to a mating connector 2604a of a host system 2608. 

tion. The External bus interface 2606 may, for example, comprise a 

downloaded decryption program 3904 could engage in an PCMCIA (or other standard) bus interface to allow portable 

interactive secure appliance 2600 to interface with and communicate over a 

protocol dialogue (3802) with PPE 650 to demonstrate that bus 2607 of host system 2608. Host 2608 may, for example, 

it has not been 20 be almost any device imaginable, such as a computer, a pay 

tampered with, as a precondition to creating and delivering telephone, another VDE electronic appliance 600, a 

the encrypted printable content 3902. The decryption television, an arcade video game, or a washing machine, to 

program 3900 could also name a few examples, 

be downloaded (3801) to printer 3901 prior to printing one Housing 2602 may be tamper resistant. (See discussion 

or more encrypted 25 above relating to tamper resistance of SPU barrier 502.) 

content streams 3902. The decryption program 3904 could n * ui v i*nn * *u r j u j- * 

H . lf jr r e> Portable appliance 2600 in the preferred embodiment 

es roy l includes one or more SPUs 500 that may be disposed within 

after printing one or more encrypted content streams 3902 to housing 2m spu 500 may be to extemal bus 

protect interface 2606 by a bus 2610 internal to housing 2602. SPU 

itself against viewing or tampenng. 30 50Q communicates ^ host 2m (throu ^ ^ eniaJ bus 

as snown in tiu. 7UH, tne decryption program JVUU 26Q6) 

over this internal bus 2610. 

could alternatively or additionally provide a fingerprinting _ niT fAA , JLL ~ 

function-for example by selecting characters for printing S ™ 500 ma y be ?™ er&d b V * battery 2612 or other 

from several related character fonts (3910a-3910z) in a Portable power supply toat is preferably disposed within 

pattern 3911 that is generated from a fingerprint key 3912 35 housi ^ 2602 ; ? atter y f 12 ma V b \ for exa *P le > * nunu- 

using standard cryptographic and/or steganographic tech- tur t e b f tter y of * e l *P c in wal< * cs or cr f djt 

niques. Because each of the characters 3913™, 3913^, etc. calculators. Battery 2612 may be supplemented (or 

representing the letter "A" in fonts 3910a-3910z is printed re P laced ) ^ solar alls, rechargeable batteries, capacitive 

with a slightly different image, it is possible to identify the stora g e cells > etc - 

font from which each character was drawn by careful 40 A random access memory (RAM) 2614 is preferably 
examination of the printed output, and thus to reconstruct the provided within housing 2602. RAM 2614 may be con- 
pattern 3911 and from that the fingerprint key 3912. There nected to spu 500 and not directly connected to bus 2610, 
are similarly different patterns for other characters in fonts so that the contents of RAM 2614 may be accessed only by 
3910o-3910z, shown as 3913a&-3913zb, etc., permitting a the SIJU and DOt °y host 2608 (except through and as 
more efficient and/or tamper-resistant encoding of finger- 45 permitted by the SPU). Looking at FIG. 9 for a moment, 
print information. RAM 2614 may be part of RAM 534 within the SPU 500, 
For printers that use non-executable control languages, although it need not necessarily be contained within the 
such as PCL5, scrambled fonts can be used without requir- same integrated circuit or other package that houses the rest 
ing that a decryption program be downloaded or otherwise °^ lne SPU. 

installed in the printer. As shown in FIG. 70, it is possible 50 Portable appliance 2600 RAM 534 may contain, for 

download permuted font images 3921 to such printers. example, information which can be used to uniquely identify 

Scrambled fonts 3921 are created by rearranging the char- eacn instance of the portable appliance. This information 

acter images in a normal font 3920. Such fonts allow PPE ma Y De employed (e.g. as at least a portion of key or 

650 to scramble the data before it is delivered for printing, password information) in authentication, verification, 

so that it could not be easily interpreted except by being 55 decryption, and/or encryption processes, 

printed on a printer with appropriate scrambled fonts. As a Portable appliance 2600 may, in one embodiment, com- 

simple substitution cipher, this could be inverted using prise means to perform substantially all of the functions of 

automated techniques, but it provides good security against a VDE electronic appliance 600. Thus, for example, portable 

accidental disclosure. Plural scrambled fonts 3921, appliance 2600 may include the means for storing and using 

scrambled according to different patterns, could be resident 60 permissions, methods, keys, programs, and/or other 

simultaneously in the printer, and used for different sections information, and can be capable of operating as a "stand 

of the printed content or different pages. Scrambled fonts alone" VDE node. 

3921 could be downloaded and/or replaced dynamically in In a further embodiment, portable appliance 2600 may 

the printer differently for each page or other division in the perform preferred embodiment VDE functions once it has 

output. 65 been coupled to an additional external electronic appliance 

The technique of using multiple character images for 600. Certain information, such as database management 

fingerprinting shown in FIG. 70B is also applicable to permission(s), method(s), key(s), and/or other important 
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information (such as at least a portion of other VDE pro- predicted to become common for desk-top computing 

grams: administrative, user-interface, analysis, etc.) may be devices and Personal Digital Assistants. One advantageous 

stored (for example as records) at an external VDE elec- form factor for the portable electronic appliance housing 

tronic appliance 600 that may share information with por- 2602 may be, for example, a Type 1, 2, or 3 PCMCIA card 

table appliance 2600. 5 (or other derivations) having credit card or somewhat larger 

One possible "stand alone" configuration for tamper- dimensions. Such a form factor is conveniently portable, and 

resistant, portable appliance 2600 arrangements includes a may be injectable into a wide array of computers and 

tamper-resistant package (housing 2602) containing one or consumer appliances, as well as receptacles at commercial 

more processors (500, 2616) and/or other computing devices establishments such as retail establishments and banks, and 

and/or other control logic, along with random -access- io at public communications points, such as telephone or other 

memory 2614. Processors 500, 2616 may execute permis- telecommunication "booths" 

sions and methods wholly (or at least in part) within the Housing 2602 may be insertable into and removable from 
portable appliance 2600. The portable appliance 2600 may a port, slot or other receptacle provided by host 2608 so as 
have the ability to encrypt information before the informa- to be physically (or otherwise operatively) connected to a 
tion is communicated outside of the housing 2602 and/or 15 computer or other electronic appliance. The portable appli- 
decrypt received information when said received informa- ance connector 2604 may be configured to allow easy 
tion is received from outside of the housing. This version removability so that appliance 2600 may be moved to 
would also possess the ability to store at least a portion of another computer or other electronic appliance at a different 
permission, method, and/or key information securely within location for a physical connection or other operative con- 
said tamper resistant portable housing 2602 on non-volatile 20 nection with that other device. 

memory. Portable electronic appliance 2600 may provide a valu- 

Another version of portable appliance 2600 may obtain able and relatively simple means for a user to move per- 

permissions and/or methods and/or keys from a local VDE missions and methods between their (compatible) various 

electronic appliance 600 external to the portable appliance electronic appliances 600, such as between a notebook 

2600 to control, limit, or otherwise manage a user's use of 25 computer, a desktop computer and an office computer. It 

a VDE protected object. Such a portable appliance 600 may could also be used > for example, to allow a consumer to visit 

be contained within, received by, installed in, or directly a next door neighbor and allow that neighbor to watch a 

connected to, another electronic appliance 2600. movie that the consumer had acquired a license to view, or 

One example of a "minimal" configuration of portable ^TA^!?^ ™ ^ ^ ° Q T^a 

appliance 2600 would include only SPU 500 and battery 30 °f lcal dlsk that the ™ mer had ****** for unlimited 

2612 within housing 2602 (the external bus interface 2606 p ^ LI , . „ M 

and the RAM 2614 would in this case each be incorporated u Portable electromc appliance 2600 may also serve as a 

into the SPU block shown in the Figure). In other, enhanced sm f card for financia ] ^ other transactions for users to 

examples of portable appliance 2600, any or all of the cm V ] °y in a vanet y of applications such as, for 

following optional components may also be included within 35 exam P le > commercial apphcaUons. The portable electronic 

housing 2602" appliance 2600 may, for example, carry permission and/or 

- mT , • i method information used to authorize (and possibly record) 

one or more CPUs 2616 (with associated support com- commercial processes and services 

ponents such as RAM-ROM 2617, I/O controllers (not An ^ usmg ^ embodiment ^ 

'* *'* 40 portable appliance 2600 for financial transactions such as 

one or more display devices 2618; mose typically per f orme d by banks and credit card compa- 

one or more keypads or other user input buttons/control n [ ts j s that VDE allows financial clearinghouses (such as 

information 2620; VISA, MasterCard, or American Express) to experience 

one or more removable/replaceable memory device(s) significant reductions in operating costs. The clearinghouse 

2622; and 45 reduction in costs result from the fact that the local metering 

one or more printing device(s) 2624. and budget management that occurs at the user site through 

In such more enhanced versions, the display 2618, keypad the use of a VDE electronic appliance 600 such as portable 

2620, memory device 2622 and printer 2624 may be con- appliance 2600 frees the clearinghouse from being involved 

nccted to bus 2610, or they might be connected to CPU 2 6 16 in every transaction. In contrast to current requirements, 

through an I/O port/controller portion (not shown) of the 50 clearinghouses will be able to perform their functions by 

CPU. Display 2618 may be used to display in formation from periodically updating their records (such as once a month). 

SPU 500, CPU 2616 and/or host 2608. Keypad 2620 may be Audit and/or budget "roll-ups" may occur during a connec- 

used to input information to SPU 500, CPU 2616 and/or host tion initiated to communicate such audit and/or budget 

2608. Printer 2624 may be used to print information from information and/or through a connection that can occur at 

any/all of these sources. Removable/replaceable memory 55 periodic or relatively periodic intervals and/or during a 

2622 may comprise a memory cartridge or memory medium credit updating, purchasing, or other portable appliance 

such as a bulk storage device, for providing additional 2600 transaction. 

long-term or short-term storage. Memory 2622 may be Clearinghouse VDE digital distribution transactions 

easily removable from housing 2602 if desired. would require only occasional authorization and/or audit or 

In one example embodiment, portable appliance 26 0 0 60 other administrative "roll-ups" to the central service, rather 

may have the form factor of a "smart card" (although a than far more costly connections during each session. Since 

"smart card" form factor may provide certain advantages, there would be no requirement for the maintenance of a 

housing 2602 may have the same or different form factor as credit card purchase "paper trail" (the authorization and then 

"conventional" smart cards). Alternatively, such a portable forwarding of the credit card slip), there could be substantial 

electronic appliance 2600 may, for example, be packaged in 65 cost reductions for clearinghouses (and, potentially, lower 

a PCMCIA card configuration (or the like) which is cur- costs to users) due to reduction in communication costs, 

rently becoming quite popular on personal computers and is facilities to handle concurrent processing of information, 
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and paper handling aspects of transaction processing costs. 
This use of a portable appliance 2600 would allow credit 
enforcement to exploit distributed processing employing the 
computing capability in each VDE electronic appliance 600. 
These credit cost and processing advantages may also apply 5 
to the use of non-smart card and non-portable VDE elec- 
tronic appliance 600s. 

Since VDE 100 may be configured as a highly secure 
commercial environment, and since the authentication pro- 
cesses supported by VDE employ digital signature processes 10 
which provide a legal validation that should be equivalent to 
paper documentation and handwritten signatures, the need 
for portable appliance 2600 to maintain paper trails, even for 
more costly transactions, is eliminated. Since audi table 
billing and control mechanisms are built into VDE 100 and 15 
automated, they may replace traditional electronic interfaces 
to VISA, Master Card, AMEX, and bank debit accounts for 
digitally distributed other products and services, and may 
save substantial operating costs for such clearinghouses. 

Portable appliance 2600 may, if desired, maintain for a 20 
consumer a portable electronic history. The portable history 
can be, for example, moved to an electronic "dock" or other 
receptacle, in or operatively connected to, a computer or 
other consumer host appliance 2608. Host appliance 2608 
could be, for example, an electronic organizer that has 25 
control logic at least in part in the form of a microcomputer 
and that stores information in an organized manner, e.g., 
according to tax and/or other transaction categories (such as 
type of use or activity). By use of this arrangement, the 
consumer no longer has to maintain receipts or otherwise 30 
manually track transactions but nevertheless can maintain an 
electronic, highly secure audit trail of transactions and 
transaction descriptions. The transaction descriptions may, 
for example, securely include the user's digital signature, 
and optionally, the service or goods provider's digital sig- 35 
nature. 

When a portable appliance 2600 is "docked" to a host 
2608 such as a personal computer or other electronic appli- 
ance (such as an electronic organizer), the portable appliance 
2600 could communicate interim audit information to the 40 
host. In one embodiment, this information could be read, 
directly or indirectly, into a computer or electronic organizer 
money and/or tax management program (for example, 
Quicken or Microsoft Money and/or Turbo Tax and/or 
Andrew Tobias* Managing Your Money). This automation 45 
of receipt management would Q>& an enormous boon to 
consumers, since the management and maintenance of 
receipts is difficult and time-consuming, receipts are often 
lost or forgotten, and the detail from credit card billings is 
often wholly inadequate for billing and reimbursement pur- 50 
poses since credit card billings normally don't provide 
sufficient data on the purchased items or significant trans- 
action parameters. 

In one embodiment, the portable appliance 2600 could 
support secure (in this instance encrypted and/or 55 
authenticated) two-way communications with a retail termi- 
nal which may contain a VDE electronic appliance 600 or 
communicate with a retailer's or third party provider's VDE 
electronic appliance 600. During such a secure two-way 
communication between, for example, each participant's 60 
secure VDE subsystem, portable appliance 2600 VDE 
secure subsystem may provide authentication and appropri- 
ate credit or debit card information to the retail terminal 
VDE secure subsystem. During the same or different com- 
munication session, the terminal could similarly, securely 65 
communicate back to the portable appliance 2600 VDE 
secure subsystem details as to the retail transaction (for 
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example, what was purchased and price, the retail establish- 
ment's digital signature, the retail terminal's identifier, tax 
related information, etc.). 

For example, a host 2608 receptacle for receiving and/or 
attaching to portable appliance 2600 could be incorporated 
into or operatively connected to, a retail or other commercial 
establishment terminal. The host terminal 2608 could be 
operated by either a commercial establishment employee or 
by the portable appliance 2600 holder. It could be used to, 
for example, input specific keyboard and/or voice input 
specific information such as who was taken to dinner, why 
something was purchased, or the category that the informa- 
tion should be attached to. Information could then be auto- 
matically "parsed" and routed into securely maintained (for 
example, encrypted) appropriate database management 
records within portable appliance 2600. Said "parsing" and 
routing would be securely controlled by VDE secure sub- 
system processes and could, for example, be based on 
category information entered in by the user and/or based on 
class of establishment and/or type (category) of expenditure 
information (or other use). Categorization can be provided 
by the retail establishment, for example, by securely com- 
municating electronic category information as a portion, for 
example, of electronic receipt information or alternatively 
by printing a hard copy receipt using printer 2624. This 
process of categorization may take place in the portable 
appliance 2600 or, alternatively, it could be performed by the 
retail establishment and periodically "rolled-up" and com- 
municated to the portable appliance 2600 holder. 

Retail, clearinghouse, or other commercial organizations 
may maintain and use by securely communicating to appli- 
ance 2600 one or more of generic classifications of trans- 
action types (for example, as specified by government 
taxation rules) that can be used to automate the parsing of 
information into records and/or for database information 
"roll-ups" for; and/or in portable appliance 2600 or one or 
more associated VDE nodes. In such instances, host 2608 
may comprise an auxiliary terminal, for example, or it could 
comprise or be incorporated directly within a commercial 
establish menls cash registers or other retail transactions 
devices. The auxiliary terminal could be menu and/or icon 
driven, and allow very easy user selection of categorization. 
It could also provide templates, based on transaction type, 
that could guide the user through specifying useful or 
required transaction specific information (for example, pur- 
pose for a business dinner and/or who attended the dinner). 
For example, a user might select a business icon, then select 
from travel, sales, meals, administration, or purchasing icons 
for example, and then might enter in very specific informa- 
tion and/or a key word, or other code that might cause the 
downloading of a transaction's detail into the portable 
appliance 2600. This information might also be stored by the 
commercial establishment, and might also be communicated 
to the appropriate government and/or business organizations 
for validation of the reported transactions (the high level of 
security of auditing and communications and authentication 
and validation of VDE should be sufficiently trusted so as 
not to require the maintenance of a parallel audit history, but 
parallel maintenance may be supported, and maintained at 
least for a limited period of time so as to provide backup 
information in the event of loss or "failure" of portable 
appliance 2600 and/or one or more appliance 2600 associ- 
ated VDE installations employed by appliance 2600 for 
historical and/or status information record maintenance). 
For example, of a retail terminal maintained necessary 
transaction information concerning a transaction involving 
appliance 2600, it could communicate such information to a 



03/04/2003, EAST Version: 1.03.0002 



5,8" 

259 

clearinghouse for archiving (and/or other action) or it could 
periodically, for example, at the end of a business day, 
securely communicate such information, for example, in the 
form of a VDE content container object, to a clearinghouse 
or clearinghouse agent. Such transaction history (and any 
required VDE related status information such as available 
credit) can be maintained and if necessary, employed to 
reconstruct the information in a portable appliance 2600 so 
as to allow a replacement appliance to be provided to an 
appliance 2600 user or properly reset internal information in 
data wherein such replacement and/or resetting provides all 
necessary transaction and status information. 

In a retail establishment, the auxiliary terminal host 2608 
might take the form of a portable device presented to the 
user, for example at the end of a meal. The user might place 
his portable appliance 2600 into a smart card receptacle such 
as a PCMCIA slot, and then enter whatever additional 
information that might appropriately describe the transac- 
tion as well as satisfying whatever electronic appliance 600 
identification procedure(s) required. The transaction, given 
the availability of sufficient credit, would be approved, and 
transaction related information would then be communi- 
cated back from the auxiliary terminal directly into the 
portable appliance 2600. This would be a highly convenient 
mode of credit usage and record management. 

The portable device auxiliary terminal might be "on-line," 
that is electronically communicating back to a commercial 
establishment and/or third party information collection point 
through the use of cellular, satellite, radio frequency, or other 
communications means. The auxiliary terminal might, after 
a check by a commercial party in response to receipt of 
certain identification information at the collection point, 
communicate back to the auxiliary terminal whether or not 
to accept the portable appliance 2600 based on other 
information, such as a bad credit record or a stolen portable 
appliance 2600. Such a portable auxiliary terminal would 
also be very useful at other commercial establishments, for 
example at gasoline stations, rental car return areas, street 
and stadium vendors, bars, and other commercial establish- 
ments where efficiency would be optimized by allowing 
clerks and other personnel to consummate transactions at 
points other than traditional cash register locations. 

As mentioned above, portable appliance 2600 may com- 
municate from time to time with other electronic appliances 
600 such as, for example, a VDE administrator. Communi- 
cation during a portable appliance 2600 usage session may 
result from internally stored parameters dictating that the 
connection should take place during that current session (or 
next or other session) of use of the portable appliance. The 
portable appliance 600 can carry information concerning a 
real-time date or window of time or duration of time that 
will, when appropriate, require the communication to take 
place (e.g., perhaps before the transaction or other process 
which has been contemplated by the user for that session or 
during it or immediately following it). Such a communica- 
tion can be accomplished quickly, and could be a secure, 
VDE two-way communication during which information is 
communicated to a central information handler. Certain 
other information may be communicated to the portable 
appliance 2600 and/or the computer or other electronic 
appliance to which the portable appliance 2600 has been 
connected. Such communicated other information can 
enable or prevent a contemplated process from proceeding, 
and/or make the portable appliance 2600, at least in part, 
unusable or useable. Information communicated to the por- 
table appliance 2600 could include one or more modifica- 
tions to permissions and methods, such as a resetting or 
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increasing of one or more budgets, adding or withdrawing 
certain permissions, etc. 

The permissions and/or methods (i.e., budgets) carried by 
the portable appliance 2600 may have been assigned to it in 

5 conjunction with an "encumbering" of another, stationary or 
other portable VDE electronic appliance 600. In one 
example, a portable appliance 2600 holder or other VDE 
electronic appliance 600 and/or VDE electronic appliance 
600 user could act as "guarantor" of the financial aspects of 

10 a transaction performed by another party. The portable 
appliance 2600 of the holder would record an 
"encumbrance/' which may be, during a secure communi- 
cation with a clearinghouse, be recorded and maintained by 
the clearinghouse and/or some other financial services party 

15 until all or a portion of debt responsibilities of the other party 
were paid or otherwise satisfied. Alternatively or in addition, 
the encumbrance may also be maintained within the portable 
appliance 2600, representing the contingent obligation of the 
guarantor. The encumbrance may be, by some formula, 

20 included in a determination of the credit available to the 
guarantor. The credit transfer, acceptance, and/or record 
management, and related processes, may be securely main- 
tained by the security features provided by aspects of the 
present invention. Portable appliance 600 may be the sole 

25 location for said permissions and/or methods for one or 
more VDE objects 300, or it may carry budgets for said 
objects that are independent of budgets for said objects that 
are found on another, non-portable VDE electronic appli- 
ance 600. This may allow budgets, for example, to be 

30 portable, without requiring "encumbering" and budget rec- 
onciliation. 

Portable VDE electronic appliance 2600 may carry (as 
may other VDE electronic appliance 600s described) infor- 
mation describing credit history details, summary of 

35 authorizations, and usage history information (e.g., audit of 
some degree of transaction history or related summary 
information such as the use of a certain type/class of 
information) that allows re-use of certain VDE protected 
information at no cost or at a reduced cost. Such usage or 

40 cost of usage may be contingent, at least in part, on previous 
use of one or more objects or class of objects or amount of 
use, etc., of VDE protected information. 

Portable appliance 2600 may also carry certain informa- / 
tion which may be used, at least in part, for identification 

45 purposes. This information may be employed in a certain 
order (e.g. a pattern such as, for example, based on a 
pseudo-random algorithm) to verify the identity of the 
carrier of the portable appliance 2600. Such information 
may include, for example, one's own or a wife's and/or other 

50 relatives maiden names, social security number or numbers 
of one's own and/or others, birth dates, birth hospitals), and 
other identifying information. It may also or alternatively 
provide or include one or more passwords or other infor- 
mation used to identify or otherwise verify/authenticate an 

55 individual's identity, such as voice print and retinal scan 
information. For example, a portable appliance 2600 can be 
used as a smart card that carries various permissions and/or 
method information for authorizations and budgets. This 
information can be stored securely within portable appliance 

60 2 600 in a secure database 610 arrangement. When a user 
attempts to purchase or license an electronic product or 
otherwise use the "smart card" to authorize a process, 
portable appliance 2600 may query the user for identifica- 
tion information or may initiate an identification process 

65 employing scanned or otherwise entered information (such 
as user fingerprint, retinal or voice analysis or other tech- 
niques that may, for example, employ mapping and/or 
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matching of provided characteristics to information securely 
stored within the portable appliance 2600). 'JTie portable 
appliance 2600 may employ different queries at different 
times (and/or may present a plurality of queries or requests 
for scanning or otherwise entering identifying information) 
so as to prevent an individual who has come into possession 
of appropriate information for one or more of the "tests" of 
identity from being able to successfully employ the portable 
appliance 2600. 

A portable appliance 600 could also have the ability to 
transfer electronic currency or credit to another portable 
appliance 2600 or to another individual's account, for 
example, using secure VDE communication of relevant 
content between secure VDE subsystems. Such transfer may 
be accomplished, for example, by telecommunication to, or 
presentation at, a bank which can transfer credit and/or 
currency to the other account. The transfer could also occur 
by using two cards at the same portable appliance 2600 
docking station. For example, a credit transaction worksta- 
tion could include dual PCMCIA slots and appropriate credit 
and/or currency transfer application software which allows 
securely debiting one portable appliance 2600 and "credit- 
ing" another portable appliance (i.e., debiting from one 
appliance can occur upon issuing a corresponding credit 
and/or currency to the other appliance). One portable appli- 
ance 600, for example, could provide an authenticated credit 
to another user. Employing two "smart card" portable appli- 
ance 600 would enable the user of the providing of "credit** 
"smart card" to go through a transaction process in which 
said user provides proper identification (for example, a 
password) and identifies a "public key" identifying another 
"smart card" portable appliance 2600. The other portable 
appliance 2600 could use acceptance processes, and provide 
proper identification for a digital signature (and the credit 
and/or currency sender may also digitally sign a transaction 
certificate so the sending act may not be repudiated and this 
certificate may accompany the credit and/or currency as 
VDE container content. The transactions may involve, for 
example, user interface interaction that stipulates interest 
and/or other terms of the transfer. It may employ templates 
for common transaction types where the provider of the 
credit is queried as to certain parameters describing the 
agreement between the parties. The receiving portable appli- 
ance 2600 may iteratively or as a whole be queried as to the 
acceptance of the terms. VDE negotiation techniques 
described elsewhere in this application may be employed in 
a smart card transfer of electronic credit and/or currency to 
another VDE smart card or other VDE installation. 

Such VDE electronic appliance 600/portablc appliance 
2600 credit transfer features would significantly reduce the 
overhead cost of managing certain electronic credit and/or 
currency activities by significantly automating these pro- 
cesses through extending the computerization of credit con- 
trol and credit availability that was begun with credit cards 
and extended with debit cards. The automation of credit 
extension and/or currency transfer and the associated dis- 
tributed processing advantages described, including the 
absence of any requirement for centralized processing and 
telecommunications during each transaction, truly make 
credit and/or currency, for many consumers and other elec- 
tronic currency and/or credit users, an efficient, trusted, and 
portable commodity. 

The portable appliance 2600 or other VDE electronic 
appliance 600, can, in one embodiment, also automate many 
tax collection functions. A VDE electronic appliance 600 
may, with great security, record financial transactions, iden- 
tify the nature of the transaction, and identify the required 
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sales or related government transaction taxes, debit the taxes 
from the users available credit, and securely communicate 
this information to one or more government agencies 
directly at some interval (for example monthly), and/or 

5 securely transfer this information to, for example, a financial 
clearinghouse, which would then transfer one or more 
secure, encrypted (or unsecure, calculated by clearinghouse, 
or otherwise computed) information audit packets (e.g., 
VDE content containers and employing secure VDE com- 

10 munication techniques) to the one or more appropriate, 
participating government agencies. The overall integrity and 
security of VDE 100 could ensure, in a coherent and 
centralized manner, that electronic reporting of tax related 
information (derived from one or more electronic commerce 

is activities) would be valid and comprehensive. It could also 
act as a validating source of information on the transfer of 
sales tax collection (e.g., if, for example, said funds are 
transferred directly to the government by a commercial 
operation and/or transferred in a manner such that reported 

20 tax related information cannot be tampered with by other 
parties in a VDE pathway of tax information handling). A 
government agency could select transactions randomly, or 
some subset or all of the reported transactions for a given 
commercial operation can be selected. This could be used to 

25 ensure that the commercial operation is actually paying to 
the government all appropriate collected funds required for 
taxes, and can also ensure that end-users are charged appro- 
priate taxes for their transactions (including receipt of inter- 
est from bank accounts, investments, gifts, etc. 

30 Portable appliance 2600 financial and tax processes could 
involve template mechanisms described elsewhere herein. 
While such an electronic credit and/or currency management 
capability would be particularly interesting if managed at 
least in part, through the use of a portable appliance 2600, 

35 credit and/or currency transfer and similar features would 
also be applicable for non-portable VDE electronic appli- 
ance 600's connected to or installed within a computer or 
other electronic device. 

40 User Notification Exception Interface 

("Pop Up") 686 

As described above, the User Modification Exception 
Interface 686 may be a set of user interface programs for 
handling common VDE functions. These applications may 
be forms of VDE templates and are designed based upon 
certain assumptions regarding important options, 
specifically, appropriate to a certain VDE user model and 
important messages that must be reported given certain 
events A primary function of the "pop-up" user interface 686 

50 is to provide a simple, consistent user interface to, for 
example, report metering events and exceptions (e.g., any 
condition for which automatic processing is either impos- 
sible or arguably undesirable) to the user, to enable the user 
to configure certain aspects of the operation of her electronic 

55 appliance 600 and, when appropriate, to allow the user to 
interactively control whether to proceed with certain trans- 
action processes. If an object contains an exception handling 
method, that method will control how the "pop-up" user 
interface 686 handles specific classes of exceptions. 

The "pop-user** interface 686 normally enables handling 
of tasks not dedicated to specific objects 300, such as for 
example: 

Logging onto an electronic appliance 600 and/or entering 
6 5 into a VDE related activity or class of activities, 

Configuring an electronic appliance 600 for a registered 
user, and/or generally for the installation, with regard to 
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user preferences, and automatic handling of certain budgets to be used with one or more objects. Selection of 

types of exceptions, options may be applied to types (that is classes) of objects 

Where appropriate, user selecting of meters for use with by associating the instruction with one or more identifying 

specific properties, and parameters related to the desired one or more types. User 

Providing an interface for communications with other 5 specified configuration information can set default values to 

electronic appliances 600, including requesting and/or be used in various situations, and can be used to limit the 

for purchasing or leasing content from distributors, number or type of occasions on which the user's use of an 

requesting clearinghouse credit and/or budgets from a object is interrupted by a "pop-up" interface 686 dialog. For 

clearinghouse, sending and/or receiving information to example, the user might specify that a user request for VDE 

and/or from other electronic appliances, and so on. 10 protected content should be automatically processed without 

FIG. 72A shows an example of a common "logon" VDE interruption (resulting from an exceptions action) if the 

electronic appliance 600 function that may use user interface requested processing of information will not cost more than 

686. "Log-on** can be done by entering a user name, account $25.00 and if the total charge for the entire current session 

name, and/or password. As shown in the provided example, (and/or day and/or week, etc.) is not greater than $200.00 

a configuration option provided by the "pop-up" user inter- 15 and if the total outstanding and unpaid charge for use hasn't 

face 686 dialog can be "Login at Setup", which, if selected, exceeded $2500.00. 

will initiate a VDE Login procedure automatically every Pop-up user interface dialogs may also be used to notify 

time the user's electronic appliance 600 is turned on or reset the user about significant conditions and events. For 

Similarly, the "pop -up" user interface 686 could provide an example, interface 686 may be used to: 

interface option called "Login at Type" which, if selected, 20 remind the user to send audit information to a 

will initiate a procedure automatically every time, for clearinghouse, 

example, a certain type of object or specific content type lnform , ^ ^ a budg6t valu6 ^ , ow and needs 

application is opened such as a file in a certain directory, a replenishing 

computer application or file with a certain identifying . ■ , . . , ^« 

. . ... „ remind the user to back up secure database 610, and 

extension, or the like. 25 r * 

FIG. 72B shows an example of a "pop-up" user interface inform the user about expirations of PERCs or other 

686 dialog that is activated when an action by the user has dates/times events 

been "trapped," in this case to warn the user about the 0lbcr important "pop-up" user interface 686 functions 

amount of expense that will be incurred by the user's action, include dialogs which enable flexible browsing through 

as well as to alert the user about the object 300 which has 30 libraries of properties or objects available for licensing or 

been requested and what that particular object will cost to purchase, either from locally stored VDE protected objects 

use. In this example, the interface dialog provides a button and /° r from one or more various, remotely located content 

allowing the user to request further detailed information providers. Such function may be provided either while the 

about the object, including full text descriptions, a list of user,s computer is connected to a remote distributor's or 

associated files, and perhaps a history of past usage of the 35 clearinghouse's electronic appliance 600, or by activating an 

object including any residual rights to use the object or electronic connection to a remote source after a choice (such 

associated discounts. ^ a property, a resource location, or a class of objects or 

The "Cancel" button 2660 in FIG. 72B cancels the user's resources is selected). A browsing interface can allow this 

trapped request. "Cancel" is the default in this example for electronic connection to be made automatically upon a user 

this dialog and can be activated, for example, by the return 40 selection of an item, or the connection itself can be explicitly 

and enter keys on the user's keyboard 612, by a "mouse activated by the user. See FIG. 72D for an example of such 

click" on that button, by voice command, or other command a "browsing" dialog, 

mechanisms. The "Approve button" 2662, which must be Smart Obiects 
explicitly selected by a mouse click or other command 

procedure, allows the user to approve the expense and 45 VDE 100 extends its control capabilities and features to 

proceed. The "More options" control 2664 expands the "intelligent agents " Generally, an "intelligent agent" can act 

dialog to another level of detail which provides further as an emissary to allow a process that dispatches it to 

options, an example of which is shown in FIG. 72C. achieve a result the originating process specifies. Intelligent 

FIG. 72C shows a secondary dialog that is presented to agents that are capable of acting in the absence of their 

the user by the "pop-up" user interface 686 when the "More 50 dispatch process are particularly useful to allow the dis- 

options" button 2664 in FIG. 72B is selected by the user. As patching process to access, through its agent, the resources 

shown, this dialog includes numerous buttons for obtaining of a remote electronic appliance. In such a scenario, the 

further information and performing various tasks. dispatch process may create an agent (e.g., a computer 

In this particular example, the user is permitted to set program and/or control information associated with a com- 

"limits" such as, for example, the session dollar limit 55 puter program) specifying a particular desired task(s), and 

amount (field 2666), a total transaction dollar limit amount dispatch the agent to the remote system. Upon reaching the 

(field 2668), a time limit (in minutes) (field 2670), and a remote system, the "agent" may perform its assigned task(s) 

"unit limit" (in number of units such as paragraphs, pages, using the remote system's resources. This allows the dis- 

etc.) (field 2672). Once the user has made her selections, she patch process to, in effect, extend its capabilities to remote 

may "click on" the OKAY button (2674) to confirm the limit 60 systems where it is not present. 

selections and cause them to take effect. Using an "agent" in this manner increases flexibility. The 
Thus, pop-up user interface dialogues can be provided to dispatching process can specify, through its agent, a par- 
specify user preferences, such as setting limits on budgets ticular desired task(s) that may not exist or be available on 
and/or other aspects of object content usage during any one the remote system. Using such an agent also provides added 
session or over a certain duration of time or until a certain 65 trustedness; the dispatch process may only need to "trust" its 
point in time. Dialogs can also be provided for selecting agent, not the entire remote system. Agents have additional 
object related usage options such as selecting meters and advantages. 
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Software agents require a high level of control and further rules 300y(l) also contained within container 300y 

accountability to be effective, safe and useful. Agents in the may describe searching and routing mechanisms that may be 

form of computer viruses have had devastating effects used to direct the smart object 3000 to a desired remote 

worldwide. Therefore, a system that allows an agent to information resource. Container 300y may contain and/or 

access it should be able to control it or otherwise prevent the 5 reference rules and control information 30Oy(l) that specify 

agent from damaging important resources. In addition, sys- the manner in which searching and routing information use 

terns allowing themselves to be accessed by an agent should and any changes may be paid for. 

sufficiently trust the agent and/or provide mechanisms Container 300* is an optional content container that is 
capable of holding the true dispatcher of the agent respon- initially "empty" when the smart object 3000 is dispatched 
sible for the agent's activities. Similarly, the dispatching 1Q to a remote site. It contains rules and control information 
process should be able to adequately limit and/or control the 309*(1) for storing the content that is retrieved by the 
authority of the agents it dispatches or else it might become execution of the agent contained in container 300z. Con- 
responsible for unforeseen activities by the agent (e.g., the taincr ma Y also contain limits on the value of content 
agent might run up a huge bill in the course of following 1031 is stored in me retrieval container so as to limit the 
imprecise instructions it was given by the process that 1C amount of content that is retrieved 

dispatched irt Other containers in the container 300 may include admin- 

„, . ' 4 . . ri _ A , istrative objects that contain audit and billing trails that 

T^ese sigmficant problems in using software agente have describe ^ of ^ ifl 3^ aQd 

not be adequately addressed in the past. The open, flexible cfa - mcumd for cxecutmg an agent at a remo te VDE 

control structures provided by VDE 100 addresses these node ^ exact structure of smart object 3000 ^ dep endent 

problems by providing the desired control and accountabil- 20 upon ^ type of ^ ^ controlled, the resources 

ity for software agents (e.g., agent objects). For example, it need for execution, and the types of information being 

VDE 100 positively controls content access and usage, retrieved. 

provides guarantee of payment for content used, and The smart object 3000 in the example shown in FIG. 73 
enforces budget limits for accessed content. These control may be used to control and manage the operation of an agent 
capabilities are well suited to controlling the activities of a ^ in VDE 100. The following detailed explanation of an 
dispatched agent by both the process that dispatches the example smart object transaction shown in FIG. 74 may 
agent and the resource accessed by the dispatched agent. provide a helpful, but non-limiting illustration. In this par- 
One aspect of the preferred embodiment provided by the ticular example, assume a user is going to create a smart 
present invention provides a "smart object" containing an o 1 *** 3000 mat performs a library search using the "Very 
agent. Generally, a "smart object** may be a VDE object 300 30 Fast and Efficient" software agent to search for books 
that contains some type(s) of software programs ("agents") ^ about some of ^terest (e.g "fire flies"). The 
for use with VDE control information at a VDE electronic ^f rch ««*c 15 to return a list of books to the user. 

i- /An a u * u , • - *rr\r The search engine in this example may spend no more than 

appliance 600. A basic smart object may comprise a VDE ^ , - f\ , < I . , 

t_* ^ 4 i_ . r 1 * ■ / l • 11 j/ $10.00 to find the appropriate books, may spend no more 

object 300 that, for example, contains (physically and/or c,^. in . rr r * u -~ # 

. „ v * y ' VF 3 J than $3.00 m library access or communications charges to 

35 get to the library, and may retrieve no more than $15.00 in 

a software agent, and information. All information relating to the search or use is 

at least one rule and/or control associated with the soft- to be returned to the user and the user will permit no 

ware agent that governs the agent's operation. information pertaining to the user or the agent to be released 

Although this basic structure is sufficient to define a "smart to a third party. 

object," FIG. 73 shows a combination of containers and 40 In this example, a dispatching VDE electronic appliance 

control information that provides one example of a particu- 3010 constructs a smart object 3000 like the one shown in 

larly advantageous smart object structure for securely man- FIG. 73. The rule set in 806a is specified as a control set that 

aging and controlling the operation of software agents. contains the following elements: 

As shown in FIG. 73, a smart object 3000 may be 1. a smart_agent_execution event that specifies the smart 

constructed of a container 300, within which is embedded 45 agent is stored in embedded container 300z and has rules 

one or more further containers (300z, 300y, etc.). Container controlling its execution specified in that container; 

300 may further contain rules and control information for 2. a smart_agenl_use event that specifies the smart agent 

accessing and using these embedded containers 300z, 300y, will operate using information and parameters stored in 

etc. Container 300z embedded in container 300 is what container 300; 

makes the object 3000 a "smart object." It contains an so 3. a routing__usc event that specifics the information routing 

"agent" that is managed and controlled by VDE 100. information is stored in container 300y and has rules 

The rules and control information 806/ associated with controlling this information stored in that container; 

container 300z govern the circumstances under which the 4. an inforraation_write event that specifies information 

agent may be released and executed at a remote VDE site, written will be stored in container 300y, 300x; or 300V 

including any limitations on execution based on the cost of 55 depending on its type (routing, retrieved, or 

execution for example. This rule and control information administrative), and that these containers have indepen- 

may be specified entirely in container 300z, and/or may be dent rules that control how information is written into 

delivered as part of container 300, as part of another them. 

container (either within container 300 or a separately deliv- Tlie rule set in control set 8066 contains rules that specify 

erable container), and/or may be already present at the 60 the rights desired by this smart object 3000. Specifically, this 

remote VDE site. control set specifies that the software agent desires: 

The second container 300y is optional, and contains 1. Aright to use the "agent execution" service on the remote 

content that describes the locations at which the agent stored VDE site. Specific billing and charge information for this 

in container 3002 may be executed. Container 300y may also right is carried in container 3002. 

contain rules and control information 806e that describe the 65 2. A right to use the "software description list" service on the 

manner in which the contents of container 300y may be used remote VDE site. Specific billing and charge information 

or altered. This rule and control information 806e and/or for this for this right is carried in container 300y. 
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3. A right to use an "information locator service" on a remote 
VDE site. 

4. A right to have information returned to the user without 
charge (charges to be incurred on release of information 
and payment will be by a VISA budget). 5 

5. Aright to have all audit information returned such that it 
is readable only by the sender. 

The rule set in control set 806c specifies that container 
300»v specifies the handling of all events related to its use. 
The rule set in control set 806d specifies that container 30ttx 10 
specifies the handling of all events related to its use. The rule 
set in control set 806e specifies that container 300y specifics 
the handling of all events related to its use. The rule set in 
control set 806/ specifies that container 300z specifies the 
handling of all events related to its use. 15 

Container 300z is specified as containing the "Very Fast 
and Efficient" agent content, which is associated with the 
following rules set: 

1. A use event that specifies a meter and VISA budget that 
limits the execution to $10.00 charged against the owner's 20 
VISA card. Audits of usage are required and will be stored 
in object 300w under control information specified in that 
object. 

After container 300z and its set are specified, they are 
constructed and embedded in the smart object container 300. 25 

Container 300y is specified as a content object with two 
types of content. Content type A is routing information and 
is read/write in nature. Content type A is associated with a 
rules set that specifies: 

1. A use event that specifics no operation for the release of 30 
the content. This has the effect of not charging for the use 

of the content. 

2. A write event that specifies a meter and a VISA budget 
that limits the value of writing to $3.00. The billing 
method used by the write is left unspecified and will be 35 
specified by the control method that uses this rule. 

3. Audits of usage are required and will be stored in object 
300u> under control information specified in that object. 
Content type B is information that is used by the software 

agent to specify parameters for the agent. This content is 40 
specified as the string "fire fly" or "fire flies". Content type 
B is associated with the following rule set: 

1. A use event that specifies that the use may only be by the 
software agent or a routing agent. The software agent has 
read only permission, the routing agent has read/write 45 
access to the information. There are no charges associated 
with using the information, but two meters; one by read 
and one by write are kept to track use of the information 
by various steps in the process. 

2. Audits of usage arc required and will be stored in object 50 
300w under control information specified in that object. 
After container 300y and its control sets are specified, 

they are constructed and embedded in the smart object 
container 300. 

Container 300* is specified as a content object that is 55 
empty of content. It contains a control set that contains the 
following rules: 

1 . A write_without_billing event that specifies a meter and 
a general budget that limits the value of writing to $15.00. 

2. Audits of usage are required and will be stored in object 60 
300w under control information specified in that object. 

3. An empty use control set that may be filled in by the 
owner of the information using predefined methods 
(method options). 

After container 300* and its control sets are specified, 65 
they are constructed and embedded in the smart object 
container 300. 
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Container 300w is specified as an empty administrative 
object with a control set that contains the following rules: 

1. A use event that specifies that the information contained 
in the administrative object may only be released to the 
creator of smart object container 300. 

2. No other rules may be attached to the administrative 
content in container 300>v. 

After container 300>v and its control sets are specified, 
they are constructed and embedded in the smart object 
container 300. 

At this point, the smart object has been constructed and is 
ready to be dispatched to a remote VDE site. The smart 
object is sent to a remote VDE site (e.g., using electronic 
mail or another transport mechanism) that contains an 
information locator service 3012 via path 3014. The smart 
object is registered at the remote site 3012 for the "item 
locator service." The control set in container related to "item 
locator service" is selected and the rules contained within it 
activated at the remote site 3012. The remote site 3012 then 
reads the contents of container 300y under the control of rule 
set 806/ and 300v(l), and permits writes of a list of location 
information into container 300y pursuant to these rules. The 
item locator service writes a list of three items into the smart 
object, and then "deregisters" the smart object (now con- 
taining the location information) and sends it to a site 3016 
specified in the list written to the smart object via path 3018. 
In this example, the user may have specified electronic mail 
for transport and a list of remote sites that may have the 
desired information is stored as a forwarding list. 

The smart object 3000, upon arriving at the second remote 
site 3016, is registered with that second site. The site 3016 
provides agent execution and software description list ser- 
vices compatible with VDE as a service to smart objects. It 
publishes these services and specifies that it requires $10.00 
to start the agent and $20/piece for all information returned. 
The registration process compares the published service 
information against the rules stored within the object and 
determines that an acceptable overlap does not exist. Audit 
information for all these activities is written to the admin- 
istrative object 300>v. The registration process then fails (the 
object is not registered), and the smart object is forwarded 
by site 3016 to the next VDE site 3020 in the list via path 
3022. 

The smart object 3000, upon arriving at the third remote 
site 3020, is registered with that site. The site 3020 provides 
agent execution and software description list services com- 
patible with VDE as a service to smart objects. It publishes 
these services and specifies that it requires $1.00 to start the 
agent and $0.50/piccc for all information returned. The 
registration process compares the published service infor- 
mation against the rules stored within the object and deter- 
mines that an acceptable overlap exists. The registration 
process creates a URT that specifies the agreed upon control 
information. This URT is used in conjunction with the other 
control information to execute the software agent under 
VDE control. 

The agent software starts and reads its parameters out of 
container 300y. It then starts searching the database and 
obtains 253 "hits" in the database. The list of hits is written 
to container 300* along with a completed control set that 
specifies the granularity of each item and that each item 
costs $0.50. Upon completion of the search, the budget for 
use of the service is incremented by $1.00 to reflect the use 
charge for the service. Audit information for all these 
activities is written to the administrative object 300m 

The remote site 3020 returns the now "full" smart object 
3000 back to the original sender (the user) at their VDE node 
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3010 via path 3024. Upon arrival, the smart object 3000 is 
registered and the database records are available. I"he con- 
trol information specified in container 300* is now a mix of 
the original control information and the control information 
specified by the service regarding remote release of their 5 
information. The user then extracts 20 records from the 
smart object 3000 and has $10.00 charged to her VISA 
budget at the time of extraction. 

In the above smart agent VDE examples, a certain orga- 
nization of smart object 3000 and its constituent containers 10 
is described. Other organizations of VDE and smart object 
related control information and parameter data may be 
created and may be used for the same purposes as those 
ascribed to object 3000 in the above example. 

Negotiation and Electronic Contracts 15 

An electronic contract is an electronic form of an agree- 
ment including rights, restrictions, and obligations of the 
parties to the agreement. In many cases, electronic agree- 
ments may surround the use of digitally provided content; 20 
for example, a license to view a digitally distributed movie. 
It is not required, however, that an electronic agreement be 
conditioned on the presence or use of electronic content by 
one or more parties to the agreement. In its simplest form, 
an electronic agreement contains a right and a control that 25 
governs how that right is used. 

Electronic agreements, like traditional agreements, may 
be negotiated between their parties (terms and conditions 
submitted by one or more parties may simply be accepted 
(cohesion contract) by one or more other parties and/or such 30 
other parties may have the right to select certain of such 
terms and conditions (while others may be required)). Nego- 
tiation is defined in the dictionary as "the act of bringing 
together by mutual agreement." The preferred embodiment 
provides electronic negotiation processes by which one or 35 
more rights and associated controls can be established 
through electronic automated negotiation of terms. Nego- 
tiations normally require a precise specification of rights and 
controls associated with those rights. PERC and URT struc- 
tures provide a mechanism that may be used to provide 40 
precise electronic representations of rights and the controls 
associated with those rights. VDE thus provides a "vocabu- 
lary" and mechanism by which users and creators may 
specify their desires. Automated processes may interpret 
these desires and negotiate to reach a common middle 45 
ground based on these desires. The results of said negotia- 
tion may be concisely described in a structure that may be 
used to control and enforce the results of the electronic 
agreement. VDE further enables this process by providing a 
secure execution space in which the negotiation processes) so 
are assured of integrity and confidentiality in their operation. 
The negotiation processes) may also be executed in such a 
manner that inhibits external tampering with the negotiation. 

A final desirable feature of agreements in general (and 
electronic representations of agreements in particular) is that 55 
they be accurately recorded in a non-repudiatable form. In 
traditional terms, this involves creating a paper document (a 
contract) that describes the rights, restrictions, and obliga- 
tions of all parties involved. 1 "his document is read and then 
signed by all parties as being an accurate representation of 60 
the agreement. Electronic agreements, by their nature, may 
not be initially rendered in paper. VDE enables such agree- 
ments to be accurately electronically described and then 
electronically signed to prevent repudiation. In addition, the 
preferred embodiment provides a mechanism by which 65 
human-readable descriptions of terms of the electronic con- 
tract can be provided. 
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VDE provides a concise mechanism for specifying con- 
trol sets that are VDE site interpretable. Machine interpret- 
able mechanisms are often not human readable. VDE often 
operates the negotiation process on behalf of at least one 
human user. It is thus desirable that the negotiation be 
expressible in "human readable form." VDE data structures 
for objects, methods, and load modules all have provisions 
to specify one or more DTDs within their structures. These 
DTDs may be stored as part of the item or they may be 
stored independently. The DTD describes one or more data 
elements (MDE, UDE, or other related data elements) that 
may contain a natural language description of the function of 
that item. These natural language descriptions provide a 
language independent, human readable description for each 
item. Collections of items (for example, a BUDGET 
method) can be associated with natural language text that 
describes its function and forms a term of an electronically 
specified and enforceable contract. Collections of terms (a 
control set) define a contract associated with a specific right. 
VDE thus permits the electronic specification, negotiation, 
and enforcement of electronic contracts that humans can 
understand and adhere to. 

VDE 100 enables the negotiation and enforcement of 
electronic contracts in several ways: 

it enables a concise specification of rights and control 
information that permit a common vocabulary and 
procedure for negotiation, 

it provides a secure processing environment within which 
to negotiate, 

it provides a distributed environment within which rights 
and control specifications may be securely distributed, 

it provides a secure processing environment in which 
negotiated contracts may be electronically rendered 
and signed by the processes that negotiate them, and 

it provides a mechanism that securely enforces a negoti- 
ated electronic contract. 

Types of Negotiations 

A simple form of a negotiation is a demand by one party 
to form an "adhesion" contract. There are few, if any, options 
that may be chosen by the other party in the negotiation. The 
recipient of the demand has a simple option; she may accept 
or reject the terms and conditions (control information) in 
the demand. If she accepts the conditions, she is granted 
rights subject to the specified control information. If she 
rejects the conditions, she is not granted the rights. PERC 
and URT structures may support negotiation by demand; a 
PERC or control set from a PERC may be presented as a 
demand, and the recipient may accept or reject the demand 
(selecting any permitted method options if they are 
presented). 

A common example of this type of negotiation today is the 
purchase of software under the terms of a "shrink-wrap 
license." Many widely publicized electronic distribution 
schemes use this type of negotiation. CompuServe is an 
example of an on-line service that operates in the same 
manner. The choice is simple: cither pay the specified charge 
or don't use the service or software. VDE supports this type 
of negotiation with its capability to provide PERCs and 
URTs that describe rights and control information, and by 
permitting a content owner to provide a REGISTER method 
that allows a user to select from a set of predefined method 
options. In this scenario, the REGISTER method may con- 
tain a component that is a simplified negotiation process. 

A more complex form of a negotiation is analogous to 
"haggling." In this scenario, most of the terms and condi- 
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tious are fixed, but one or more terms (e.g., price or payment Mastercard, or American Express) and it defines a BILLING 

terms) are not. For these terms, there are options, limits, and method 3110 that specifies a charge (e.g., a one-time charge 

elements that may be negotiated over. A VDE electronic of $100.00). 

negotiation between two parties may be used to resolve the Cootro , ^ ^ b [q ^ pERC 31Q0 describes anotner 

desired, permitted, and optional terms. IT* result of the 5 mechanism by which me user may obUm the content. In this 

electronic negotiation may be a finalized set of rules and , ' t . . ~ * j- 

t . . - & . 4t _ , 3 * » * . example, the control set 3102/? specifies a different vending 

control information that specify a completed electronic A r _ ' . , , A c . , . , , . j 

contract. A simple example is the scenario for purchasing ^f 01 a ^ °f rc <^<! mtihc f ™*Zr£ 

software described above adding the ability of the purchaser 0 P Uo1 ** ™* J™" 6 * l A 31 ^ Spca&s a BUDGET 

to select a method of payment (VISA, Mastercard, or 1fl method (? £ ■•; of VIS^ Mastercard, or Amencaii 

American Express). A more complex example is a scenario 10 • BILLING method 3116 that species ^a charge 

for purchasing information in which the price paid depends » Iess f r charge .f ch S2 f ^ ™ d "! 

on the amount of information about the user that is returned AUDIT method 3114 that specifics a set of desired and 

along with a usage audit trail. In this second example, the fic ds ' ™ e ficld SP«atotion 

right to use the content may be associated with two control „ 3116 ^ the form of a DTD specification, m which, for 

sets. One control set may describe a fixed ("higher") price 15 exam P le ' me field names are hsted ' 

for using the content. Another control set may describe a The content creator may "prefer" one of the two control 

fixed ("lower") price for using the content with additional sefci (e.g., control set 2) over the other one. If so, the 

control information and field specifications requiring col- "preferred" control set may be "offered" first in the nego- 

lection and return the user's personal information. In both of tiation process, and withdrawn in favor of the "non- 

these cases, the optional and permitted fields and control sets preferred" control set if the other party to the negotiation 

in a PERC may describe the options that may be selected as "rejects" the "preferred" control set. 

part of the negotiation. To perform the negotiation, one party In this example, these two control sets 3102a, 31026 may 

may propose a control set containing specific fields, control share a common BUDGET method specification. The BUD- 

information, and limits as specified by a PERC; the other ^ GET method specification may be included in the CSR 3104 

party may pick and accept from the control sets proposed, or CS0 3106 control sets if desired. Selecting control set 

reject them, or propose alternate control sets that might be 3102a (use with no information passback) causes a unique 

used. The negotiation process may use the permitted, component assembly to be assembled as specified by the 

required, and optional designations in the PERC to deter- PERC 3100. Specifically, in this example it selects the 

mine an acceptable range of parameters for the final rule set. ^ "\fending" CONTROL method 3118, the BILLING method 

Once an agreement is reached, the negotiation process may 3110 for a $100 fixed charge, and the rest of the control 

create a new PERC and/or URT that describes the result of information specified by CSR 3104 and CS0 3106. It also 

the negotiation. The resulting PERCs and/or URTs may be requires the user to specify her choice of acceptable BUD- 

"signed" (e.g., using digital signatures) by all of the nego- GET method (e.g., from the list including VISA, 

tiation processes involved in the negotiation to prevent 35 Mastercard, and American Express). Selecting control set 

repudiation of the agreement at a later date. 31026 assembles a different component assembly using the 

Additional examples of negotiated elements are: elec- "\fcnding with * response card*" CONTROL method 3120, 

tronic cash, purchase orders, purchase certificates (gift the BILLING method 3116 (e.g., for a $25 fixed charge), an 

certificates, coupons), bidding and specifications, budget AUDIT method 3114 that requires the fields listed in the 

"rollbacks" and reconciliation, currency exchange rates, ^ Required Fields DTD 3116. The process may also select as 

stock purchasing, and billing rates. many of the fields listed in the Desired Fields DTD 3116 as 

A set of PERCs that might be used to support the second are made available to it. The rest of the control information 

example described above is presented in FIGS. 75A(PERC ^ specified by CSR 3104 and CS0 3106. The selection of 

sent by the content owner), 75B (PERC created by user to control set 31026 also forces the user to specify their choice 

represent their selections and rights), and 75C (PERC for 45 of acceptable BUDGET methods (e.g., from the list includ- 

controlling the negotiation process). These PERCs might be i"g VISA, Mastercard, and American Express), 

used in conjunction with any of the negotiation process(es) FIG. 75B shows an example of a control set 3125 that 

and protocols described later in this section. might be used by a user to specify her desires and require- 

FIG. 75A shows an example of a PERC 3100 that might ments in a negotiation process. This control set has a USE 

be created by a content provider to describe their rights 50 rights section 3127 that contains an aggregated CSR budget 

options. In this example, the PERC contains information specification 3129 and two optional control sets 3131a, 

regarding a single USE right. Two alternate control sets 31316 for use of the content. Control set 3131a requires the 

3102a, 31026 are presented for this right in the example. use of a specific CONTROL method 3133 and AUDIT 

Control set 3102a permits the use of the content without method 3135. The specified AUDIT method 3135 is param- 

passing back information about the user, and another control 55 eterized with a list of fields 3137 that may be released in the 

set 31026 permits the use of the content and collects audit trail. Control set 3131a also specifies a BILLING 

"response card" type information from the user. Both control method 3139 that can cost no more than a certain amount 

sets 3102a, 31026 may use a common set of methods for (e.g., $30.00). Control set 31316 in this example describes 

most of the control information. This common control a specific CONIKOL method 3141 and may reference a 

information is represented by a CSR 3104 and CS0 3106. 60 BILLING method 3143 that can cost no more than a certain 

Control set 3102a in this PERC 3100 describes a mecha- amount (e.g., $150.00) if this option is selected, 

nism by which the user may obtain the content without FIG. 75E shows a more high-level view of an electronic 

providing any information about its user to the content contract 3200 formed as a "result" of a negotiation process 

provider. This control set 3102a specifies a well-known as described above. Electronic contract 3200 may include 

vending control method and set of required methods and 65 multiple clauses 3202 and multiple digital signatures 3204. 

method options. Specifically, in this example, control set Each clause 3202 may comprise a PERC/URT such as item 

3102a defines a BUDGET method 3108 (e.g., one of VISA, 3160 described above and shown in FIG. 75D. Each 
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"clause" 3202 of electronic contract 3200 thus corresponds to impose syntax rules that bind different textual elements 
to a component assembly 690 that may be assembled and together into a coherent, humanly readable contract docu- 
cxccuted by a VDE electronic appliance 600. Just as in mcnt. Such text could, if necessary, be reviewed and modi- 
normal contracts there may be as many contract clauses fied by a "human" attorney in order customize it for the 
3202 within electronic contract 3200 as is necessary to 5 particular agreement between the parties and/or to add 
embody the "agreement" between the "parties." Each of further legal obligations augmenting the "self -executing" 
clauses 3202 may have been electronically negotiated and electronic obligations embodied within and enforced by the 
may thus embody a part of the "agreement" (e.g., a associated component assemblies 690 executing on a VDE 
"compromise") between the parties. Electronic contract electronic appliance 600. Such text could be displayed 
3200 is "self-executing" in the sense that it may be literally 10 automatically or on demand upon execution of the electronic 
executed by a machine, i.e., a VDE electronic appliance 600 contract, or it could be used to generate a printed humanly- 
that assembles component assemblies 690 as specified by rcadablc ^rsion of the contract at any time. Such a docu- 
various electronic clauses 3202. Electronic contract 3200 me * version of th f. electronic contract 3200 would not need 

may be automatically "enforced" using the same VDE <° * ^ ed ,n mk f £ TjT^ ^T^T ^ 

J , . * . iUi & , . . t . desired) in view of the fact that the digital signatures 3204 

mechamsms discussed above thai are used in conjunction 15 wouJd > ^ a sufficientl xcatt ^^evidentiary 

with any component assembly 690. For example, assuming basis for ^ the rties . n)lltual to aI1 ^ tenns 

that a clause 3202(2) corresponds to a payment or BILLING and coitions ^(bin the contract. 

condition or term, its corresponding component assembly , n ^ ferred embodiment, the negotiation process 
690 when assembled by a user s VDE electronic appliance executes within a PPE 650 under the direction of a further 
600 may automatically determine whether conditions are w pERC lhat specifies the process . nG. 75C shows an 
right for payment and, when they are, automatically access example of a PERC 3150 that specifies a negotiation pro- 
an appropriate payment mechanism (e.g., a virtual "credit cess . n, e PERC 3150 contains a single right 3152 for 
card" object for the user) to arrange that payment to be negotiation, with two permitted control sets 3154a, 3154* 
made. As another example, assuming that electronic contract described for that right. The first control set 3154a may be 
clause N 3202(N) corresponds to a user's obligation to 25 used for a "trusted negotiation"; it references the desired 
provide auditing information to a particular VDE negotiation CONTROL method ("Negotiate") 3156 and. 
participant, electronic contract 3200 will cause VDE elec- references (in fields 3157a, 31576) two UDEs that this 
tronic appliance 600 to assemble a corresponding compo- CONTROL method will use. These UDEs may be, for 
nent assembly 690 that may, for example, access the appro- example, the PERCs 3100, 3125 shown in FIGS. 75A and 
priate audit trails within secure database 610 and provide 30 75B. The second control set 31546 may be used by "multiple 
them in an administrative object to the correct participant. negotiation" processes to manage the negotiation, and may 
FIG. 75F shows that clause 3202(N) may, for example, provide two negotiation methods: "Negotiatel," and "Nego- 
specify a component assembly 690 that arranges for multiple tiate2". Both negotiation processes may be described as 
steps in a transaction 3206 to occur. Some of these steps required methods ("Negotiatel" and "Negotiate2") 3156, 
(e.g., step 3208(4), 3208(5)) may be conditional on a test 35 3158 that take respective PERCs 3100, 3125 as their inputs, 
(e.g., 3208(3)) such as, for example, whether content usage The CONTROL method 3158 for this control set in this 
has exceeded a certain amount, whether a certain time period example may specify the name of a service that the two 
has expired, whether a certain calendar date has been negotiation processes will use to communicate with each 
reached, etc. other, and may also manage the creation of the URT result- 
Digital signatures 3204 shown in the FIG. 75E electronic 40 m & from lne negotiation, 
contract 3200 may comprise, for example, conventional When executed, the negotiation processes) specified by 
digital signatures using public key techniques as described the PERC 3150 shown in FIG. 75C may be provided with 
above. Some electronic contracts 3200 may not bear any the PERCs 3100, 3125 as input that will be used as the basis 
digital signatures 3204. However, it may be desirable to for negotiation. In this example, the choice of negotiation 
require the electronic appliance 600 of the user who is a 45 process type (trusted or multiple) may be made by the 
party to the electronic contract 3200 to digitally "sign" the executing VDE node. The PERC 3150 shown in FIG. 75C 
electronic contract so that the user cannot later repudiate the might be, for example, created by a REGISTER method in 
contract, for evidentiary purposes, etc. Multiple parties to response to a register request from a user. The process 
the same contract may each digitally "sign" the same specified by this PERC 3150 may then be used by a 
electronic contract 3200 similarly to the way multiple parties so REGISTER method to initiate negotiation of the terms of an 
to a contract memorialized in a written instrument use an ink electronic contract. 

pen to sign the instrument. During this example negotiation process, the PERCs 
Although each of the clauses 3202 of electronic contract 3100, 3125 shown in FIGS. 75A and 75B act as input data 
3200 may ultimately correspond to a collection of data and structures that are compared by a component assembly 
code that may be executed by a PPE 650, there may in some 55 created based on PERC 3150 shown in FIG. 35C. The 
instances be a need for rendering a human readable version component assembly specified by the control sets may be 
of the electronic contract. This need can be accommodated assembled and compared, starting with required "terms," 
by, as mentioned above, providing text within one or more and progressing to prcfcrrcd/dcsircd "terms" and then mov- 
DTDs associated with the component assembly or assem- ing on to permitted "terms," as the negotiation continues, 
blies 690 used to "self-execute" the contract. Such text 60 Method option selections arc made using the desired method 
might, for example, describe from a functional point of view and method options specified in the PERCs 3100, 3125. In 
what the corresponding electronic contract clause 3202 this example, a control set for the PERC 3100 shown in FIG. 
means or involves, and/or might describe in legally enforce- 75A may be compared against the PERC 3125 shown in 
able terms what the legal obligation under the contract is or FIG. 75B. If there is a "match," the negotiation is success- 
represents. "Templates" (described elsewhere herein) might 65 fully concluded and "results" are generated, 
be used to supply such text from a text library. An expert In this embodiment, the results of such negotiation will 
system and/or artificial intelligence capability might be used generally be written as a URT and "signed" by the negotia- 
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tion processes) to indicate that ao agreement has been 
reached. These electronic signatures provide the means to 
show that a (virtual) "meeting of minds" was reached (one 
of the traditional legal preconditions for a contract to exist). 
An example of the UKT 3160 that would have been created 
by the above example is shown in FIG. 75D. 

This URT 3160 (which may itself be a PERC 808) 
includes a control set 3162 that reflects the "terms" that were 
"agreed upon" in the negotiation. In this example, the 
"agreed upon" terms must "match" terms required by input 
PERCs 3100, 3125 in the sense that they must be "as 
favorable as" the terms required by those PERCs. The 
negotiation result shown includes, for example, a "negoti- 
ated" control set 3162 that in some sense corresponds to the 
control set 3102a of the FIG. 75A PERC 3100 and to the 
control set 3131a of the FIG. 75B control set 3125. Result- 
ing "negotiated" control set 3162 thus includes a required 
BUDGET method 3164 that corresponds to the control set 
3125 desired BUDGET method 3142 but which is "within" 
the range of control sets allowed by control set 3100 
required BUDGET method 3112. Similarly, resulting nego- 
tiated control set 3162 includes a required AUDIT method 
3166 that complies with the requirements of both PERC 
3100 required AUDIT method 3114 and PERC 3125 
required AUDIT method 3135. Similarly, resulting negoti- 
ated control set 3162 includes a required BILLING method 
3170 that "matches" or complies with each of PERC 3100 
required BILLING method 3116 and PERC 3125 required 
BIUJNG method 3170. 

Another class of negotiation is one under which no rules 
are fixed and only the desired goals are specified. The 
negotiation processes for this type of negotiation may be 
very complex. It may utilize artificial intelligence, fuzzy 
logic, and/or related algorithms to reach their goals. VDE 
supports these types of processes by providing a mechanism 
for concisely specifying rights, control information, fields 
and goals (in the form of desired rights, control information, 
and fields). Goals for these types of processes might be 
specified as one more control sets that contain specific 
elements that are tagged as optional, permitted, or desired. 

Types of Negotiations 

Negotiations in the preferred embodiment may be struc- 
tured in any of the following ways: 

1. shared knowledge 

2. trusted negotiator 

3. "zero-based" knowledge 

"Shared knowledge" negotiations are based on all parties 
knowing all of the rules and constraints associated with the 
negotiation. Demand negotiations arc a simple case of 50 
shared knowledge negotiations; the demander presents a list 
of demands that must be accepted or rejected together The 
list of demands comprises a complete set of knowledge 
required to accept or reject each item on the list. VDE 
enables this class of negotiation to occur electronically by 
providing a mechanism by which demands may be encoded, 
securely passed, and securely processed between and with 
secure VDE subsystems using VDE secure processing, and 
communication capabilities. Other types of shared knowl- 
edge negotiations employed by VDE involve the exchange 
of information between two or more negotiating parties; the 
negotiation processes) can independently determine desired 
final outcome(s) based on their independent priorities. The 
processes can then negotiate over any differences. Shared 
knowledge negotiations may require a single negotiation 
process (as in a demand type negotiation) or may involve 
two or more cooperative processes. FIGS. 76A and 76B 



illustrate scenarios in which one and two negotiation pro- 
cesses are used in a shared knowledge negotiation. 

FIG. 76A shows a single negotiation process 3172 that 
takes any number of PERCs 808 (e.g., supplied by different 
parties) as inputs to the negotiation. The negotiation process 
3172 executes at a VDE node under supervision of "Nego- 
tiation Process Rules and Control information" that may be 
supplied by a further PERC (e.g., PERC 3150 shown in FIG. 
75C). The process 3172 generates one or more PERCs/URTs 
3160 as results of the negotiation. 

FIG. 76B shows multiple negotiation processes 
3172A-3172N each of which takes as input a PERC 808 
from a party and a further PERC 3150 that controls the 
negotiation process, and each of which generates a negoti- 
ated "result" PERCAJRT 3160 as output. Processes 
3172A-3172N may execute at the same or different VDE 
nodes and may communicate using a "negotiation protocol." 

Single and multiple negotiation processes may be used for 
specific VDE sites. The negotiation processes are named, 
and can be accessed using well known method names. 
PERCs and URTs may be transported in administrative or 
smart objects to remote VDE sites for processing at that site, 
as may the control PERCs and REGISTER method that 
controls the negotiation. 

Multiple negotiation processes require the ability to com- 
municate between these processes 3172; including secure 
communication between secure processes that are present at 
physically separate VDE sites (secure subsystems). VDE 
generalizes the inter-process communication into a securely 
provided service that can be used if the configuration 
requires it. The inter-process communication uses a nego- 
tiation protocol to exchange information about rule sets 
between processes 3172. An example of a negotiation pro- 
tocol includes the following negotiation "primitives": 
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WANT 


Want a set of terms and 




conditions 


ACCEPT 


Accept a set of terms and 




conditions 


REJECT 


Reject a set of terms and 




conditions 


OFFER 


Offer a set of terms and 




conditions in exchange for other 




terms and conditions 


HAVE 


Assert a set of terms and 




conditions are possible or 




desirable 


QUIT 


Assert the end of the negotiation 




without reaching an agreement 


AGREEMENT 


Conclude the negotiation and pass the 




rule set for signature 



The WANT primitive takes rights and control set (or parts 
of control sets) information, and asserts to the other process 
(es) 3172 that the specified terms are desired or required. 
Demand negotiations are a simple case of a WANT primitive 
being used to assert the demand. This example of a protocol 
may introduce a refined form of the WANT primitive, 
REQUIRE. In this example, REQUIRE allows a party to set 
terms that she decides are necessary for a contract to be 
formed, WANT may allow the party to set terms that are 
60 desirable but not essential. This permits a distinction 
between "must have" and "would like to have." 

In this example, WANT primitives must always be 
answered by an ACCEPT, REJECT, or OFFER primitive. 
The ACCEPT primitive permits a negotiation process 3172 
to accept a set of terms and conditions. The REJECT 
primitive permits a process 3172 to reject an offered set of 
terms and conditions. Rejecting a set of required terms and 
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conditions may terminate the negotiation. OFFER permits a 
counter-offer to be made. 

The HAVE, QUIT, and AGREEMENT primitives permit 
the negotiation protocols to pass information about rule sets. 
Shared knowledge negotiations may, for example, start with 
all negotiation processes 3172A-3172N asserting HAVE 
(my PERC) to the other processes. HAVE is also used when 
an impasse is reached and one process 3172 needs to let the 
other process 3172 know about permitted options. QUIT 
signals an unsuccessful end of the negotiation without 
reaching an agreement, while AGREEMENT signals a suc- 
cessful end of an agreement and passes the resulting "nego- 
tiated" PERC/URT 3160 to the other processes) 3172 for 
signature. 

In "trusted negotiator" negotiations, all parties provide 
their demands and preferences to a "trusted" negotiator and 
agree to be bound by her decision. This is similar to binding 
arbitration in today's society. VDE enables this mode of 
negotiation by providing an environment in which a 
"trusted" negotiation service may be created. VDE provides 
not only the mechanism by which demands, desires, and 
limits may be concisely specified (e.g., in PERCs), but in 
which the PERCs may be securely transferred to a "trusted" 
negotiation service along with a rule set that specifies how 
the negotiation will be conducted, and by providing a secure 
execution environment so that the negotiation process may 
not be tampered with. Trusted negotiator services can be 
used at VDE sites where the integrity of the site is well 
known. Remote trusted negotiation services can be used by 
VDE sites that do not possess sufficient computing resources 
to execute one or more negotiation processes); they can 
establish a communication link to a VDE site that provides 
this service and permits the service to handle the negotiation 
on their behalf. 

"Zero-based" knowledge negotiations share some char- 
acteristics of the zero-based knowledge protocols used for 
authentication. It is well understood in the art how to 
construct a protocol that can determine if a remote site is the 
holder of a specific item without exchanging or exposing the 
item. This type of protocol can be constructed between two 
negotiation processes operating on at least one VDE site 
using a control set as their knowledge base. The negotiation 
processes may exchange information about their control 
sets, and may make demands and counter proposals regard- 
ing using their individual rule sets. For example, negotiation 
process A may communicate with negotiation process B to 
negotiate rights to read a book. Negotiation process A 
specifies that it will pay not more than $10.00 for rights to 
read the book, and prefers to pay between $5.00 and $6.00 
for this right. Process A's rule set also specifies that for the 
$5.00 option, it will permit the release of the reader's name 
and address. Process B*s rule set specifies that it wants 
$50.00 for rights to read the book, and will provide the book 
for $550 if the user agrees to release information about 
himself. The negotiation might go something like this: 
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Process A 

Want (right to read, unrestricted) 



Offer (right to read, tender 
user info) 



< — > Process B 
— > 

< — I lave (right to 
read, 

unrestricted, 
$50) 

— > 

< — Have(right to 
read, tender 
user info, 
$5.50) 



Accept(right to read, tender 
user info, $5.50) 



10 



20 



25 



In the above example, process A first specifies that it 
desires the right to read the book without restrictions or other 
information release. This starting position is specified as a 
rights option in the PERC that process A is using as a rule. 
Process B checks its rules and determines that an unre- 
stricted right to read is indeed permitted for a price of $50. 
It replies to process A that these terms are available. Process 
A receives this reply and checks it against the control set in 
the PERC it uses as a rule base. The $50 is outside the $10 
limit specified for this control set, so Process A cannot 
accept the offer. It makes a counter offer (as described in 
another optional rights option) of an unrestricted right to 
read coupled with the release of the reader's name and 
address. The name and address fields are described in a DTD 
referenced by Process A's PERC. Process B checks its rules 
PERC and determines that an unrestricted right to read 
combined with the release of personal information is a 
permitted option. It compares the fields that would be 
released as described in the DTD provided by Process A 
against the desired fields in a DTD in its own PERC, and 
determines an acceptable match has occurred. It then sends 
an offer for unrestricted rights with the release of specific 
information for the cost of $5 JO to Process A. Process A 
compares the right, restrictions, and fields against its rule set 
30 and determines that $5.50 is within the range of $5-$6 
described as acceptable in its rule set. It accepts the offer as 
made. The offer is sealed by both parties "signing" a new 
PERC that describes the results of the final negotiation 
(unrestricted rights, with release of user information, for 
35 $5.50). The new PERC may be used by the owner of Process 
A to read the content (the book) subject to the described 
terms and conditions. 



Further Chain of Handling Model 

As described in connection with FIG. 2, there arc four (4) 
"participant" instances of VDE 100 in one example of a 
VDE chain of handling and control used, for example, for 
content distribution. The first of these participant instances, 
the content creator 102, is manipulated by the publisher, 
author, rights owner or distributor of a literary property to 
prepare the information for distribution to the consumer. The 
second participant instance, VDE rights distributor 106, may 
distribute rights and may also administer and analyze cus- 
tomers* use of VDE authored information. The third par- 
ticipant instance, content user 112, is operated by users 
(included end-users and distributors) when they use infor- 
mation. The fourth participant instance, financial clearing- 
house 116 enables the VDE related clearinghouse activities. 
A further participant, a VDE administrator, may provide 
support to keep VDE 100 operating properly. With appro- 
priate authorizations and Rights Operating System compo- 
nents installed, any VDE electronic appliance 600 can play 
any or all of these participant roles. 

Literary property is one example of raw material for VDE 
100. To transfer this raw material into finished goods, the 
publisher, author, or rights owner uses tools to transform 
digital information (such as electronic books, databases, 
computer software and movies) into protected digital pack- 
ages called "objects." Only those consumers (or others along 
the chain of possession such as a redistributor) who receive 
permission from a distributor 106 can open these packages. 
VDE packaged content can be constrained by "rules and 
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control information" provided by content creator 102 and/or 
content distributor 106 — or by other VDE participants in the 
content's distribution pathway, i.e., normally by participants 
"closer" to the creation of the VDE secured package than the 
participant being constrained. 

Once the content is packaged in an "object/' the digital 
distribution process may begin. Since the information pack- 
ages themselves are protected, they may be freely distributed 
on CD-ROM disks, through computer networks, or broad- 
cast through cable or by airwaves. Informal "out of channel" 
exchange of protected packages among end-users does not 
pose a risk to the content property rights. This is because 
only authorized individuals may use such packages. In fact, 
such "out of channel" distribution may be encouraged by 
some content providers as a marginal cost method of market 
penetration. Consumers with usage authorizations (e.g., a 
VISA clearinghouse budget allowing a certain dollar amount 
of usage) may, for example, be free to license classes of out 
of channel VDE protected packages provided to them, for 
example, by a neighbor. 

To open a VDE package and make use of its content, an 
end-user must have permission. Distributors 106 can grant 
these permissions, and can very flexibly (if permitted by 
senior control information) limit or otherwise specify the 
ways in which package contents may be used. Distributors 25 
106 and financial clearinghouses 116 also typically have 
financial responsibilities (they may be the same organization 
in some circumstances if desired). They ensure that any 
payments required from end-users fulfill their own and any 
other participant's requirements. This is achieved by audit- 
ing usage. 

Distributors 106 using VDE 100 may include software 
publishers, database publishers, cable, television, and radio 
broadcasters, and other distributors of information in elec- 
tronic form. VDE 100 supports all forms of electronic 
distribution, including distribution by broadcast or 
telecommunications, or by the physical transfer of electronic 
storage media. It also supports the delivery of content in 
homogeneous form, seamlessly integrating information 
from multiple distribution types with separate delivery of 
permissions, control mechanisms and content. 

Distributors 106 and financial clearinghouses 116 may 
themselves be audited based on secure records of their 
administrative activities and a chain of reliable, "trusted" 
processes ensures the integrity of the overall digital distri- 
bution process. This allows content owners, for example, to 
verify that they are receiving appropriate compensation 
based on actual content usage or other agreed-upon bases. 

Since the end-user 112 is the ultimate consumer of content 
in this example, VDE 100 is designed to provide protected 
content in a seamless and transparent way — so long as the 
end-user stays within the limits of the permissions she has 
received. The activities of end-user 112 can be metered so 
that an audit can be conducted by distributors 106. The 
auditing process may be filtered and/or generalized to satisfy 
user privacy concerns. For example, metered, recorded VDE 
content and/or appliance usage information may be filtered 
prior to reporting it to distributor 106 to prevent more 
information than necessary from being revealed about con- 
tent user 112 and/or her usage. 

VDE 100 gives content providers the ability to recreate 
important aspects of their traditional distribution strategies 
in electronic form and to innovatively structure new distri- 
bution mechanisms appropriate to their individual needs and 
circumstances. VDE 100 supports relevant participants in 
the chain of distribution, and also enables their desired 
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pricing strategies, access and redistribution permissions, 
usage rules, and related administrative and analysis proce- 
dures. The reusable functional primitives of VDE 100 can be 
flexibly combined by content providers to reflect their 
respective distribution objectives. As a result, content pro- 
viders can feed their information into established distribu- 
tion channels and also create their own personalized distri- 
bution channels. 

A summary of the roles of the various participants of 
virtual distribution environment 100 is set forth in the table 
below: 
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Role 



Description 



Content creator 



Content owner 
Distributors 
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Auditor 



Clearinghouse 



Network provider 

Financial 
providers 



End Users 



Rcdistributor 



VDE 

Administrator 
Independent 
Audit Processor 



Agents 



"Traditional" Participants 

Packager and initial distributor of digital 
information 

Owner of the digital information. 
Provide rights distribution services for 
budgets and/or content. 
Provides services for processing and 
reducing usage based audit trails. 
Provides intermediate store and forward 
services for content and audit 
information. Also, typically provides a 
platform for other services, including 
third party financial providers and 
auditors. 

Provides communication services between 
sites and other participants. 
Provider of third party sources of 
electronic funds to end-users and 
distributors. Examples of this class of 
users are VISA, American Express, or a 
government. 

Consumers of information. 
Other Participants 

Redistributes rights to use content based 
on chain of handling restrictions from 
content providers and/or other 
distributors. 

Provider of trusted services for support of 
VDE nodes. 

Provider of services for processing and 
summarizing audit trail data. Provides 
anonymity to end-users while 
maintaining the comprehensive audit 
capabilities required by the content 
providers. 

Provides distributed presence for end- 
users and other VDE participants. 
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Of these various VDE participants, the "redistributor," 
"VDE Administrator," "independent audit processor" and 
"agents" are, in certain respects "new" participants that may 
have no counterpart in many "traditional" business models. 
The other VDE participants (i.e., content provider, content 
owner, distributors, auditor, clearinghouse, network pro- 
vider and financial providers) have "traditional" business 
model counterparts in the sense that traditional distribution 
models often included non-electronic participants perform- 
ing some of the same business roles they serve in the virtual 
distribution environment 100. 

VDE distributors 106 may also include "end-users" who 
provide electronic information to other end-users. For 
example, FIG. 77 shows a further example of a virtual 
distribution environment 100 chain of handling and control 
provided by the present invention. As compared to FIG. 2, 
FIG. 77 includes a new "client administrator" participant 
700. In addition, FIG. 77 shows several different content 
users 112(1), 112(2), . . . , U2(/i) that may all be subject to 
the "jurisdiction" of the client administrator 700. Client 
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administrator 700 may be, for example, a further rights 
distributor within a corporation or other organization that 
distributes rights to employees or other organization partici- 
pant units (such as divisions, departments, networks, and or 
groups, etc.) subject to organization-specific "rules and 
control information.** The client administrator 700 may 
fashion rules and control information for distribution, sub- 
ject to "rules and control" specified by creator 102 and/or 
distributor 106. 

As mentioned above, VDE administrator 1165 is a trusted 
VDE node that supports VDE 100 and keeps it operating 
properly. In this example, VDE administrator 116/? may 
provide, among others, any of all of the following: 

VDE appliance initialization services 

VDE appliance reinitialization/update services 

Key management services 

"Hot lists" of "rogue" VDE sites 

Certification authority services 

Public key registration 

Client participant unit content budgets and other autho- 
rizations 

All participants of VDE 100 have the innate ability to 
participate in any role. For example, users may gather 
together existing protected packages, add (create new 
content) packages of their own, and create new products. 
They may choose to serve as their own distributor, or 
delegate this responsibility to others. These capabilities are 
particularly important in the object oriented paradigm which 
is entering the marketplace today. The production of com- 
pound objects, object linking and embedding, and other 
multi-source processes will create a need for these capabili- 
ties of VDE 100. The distribution process provided by VDE 
100 is symmetrical; any end-user may redistribute informa- 
tion received to other end-users, provided they possess 
permission from and follow the rules established by the 
distribution chain VDE control information governing redis- 
tribution. End-users also may, within the same rules and 
permissions restriction, encapsulate content owned by others 
within newly published works and distribute these works 
independently. Royalty payments for the new works may be 
accessed by the publisher, distributors, or end-users, and 
may be tracked and electronically collected at any stage of 
the chain. 

Independent financial providers can play an important 
role in VDE 100. The VDE financial provider role is similar 
to the role played by organizations such as VISA in tradi- 
tional distribution scenarios. In any distribution model, 
authorizing payments for use of products or services and 
auditing usage for consistency and irregularities, is critical. 
In VDE 100, these arc the roles filled by independent 
financial providers. The independent financial providers 
may also provide audit services to content providers. Thus, 
budgets or limits on use, and audits, or records of use, may 
be processed by (and may also be put in place by) clear- 
inghouses 116, and the clearinghouses may then collect 
usage payments from users 112. Any VDE user 112 may 
assign the right to process information or perform services 
on their behalf to the extend allowed by senior control 
information. The arrangement by which one VDE partici- 
pant acts on behalf of another is called a "proxy." Audit, 
distribution, and other important rights may be "proxied" if 
permitted by the content provider. One special type of 
"proxy" is the VDE administrator 116b. A VDE adminis- 
trator is an organization (which may be acting also as a 
financial clearinghouse 116) that has permission to manage 
(for example, "intervene" to reset) some portion or all of 
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VDE secure subsystem control information for VDE elec- 
tronic appliances. This administration right may extend only 
to admitting new appliances to a VDE infrastructure and to 
recovering "crashed" or otherwise inoperable appliances, 
and providing periodic VDE updates. 

More on Object Creation, Distribution Methods, 
Budgets, and Audits 

VDE node electronic appliances 600 in the preferred 
embodiment can have the ability to perform object creation, 
distribution, audit collection and usage control functions 
provided by the present invention. Incorporating this range 
of capabilities within each of many electronic appliances 
600 provided by the preferred embodiment is important to a 
general goal of creating a single (or prominent) standard for 
electronic transactions metering, control, and billing, that, in 
its sum of installations, constitutes a secure, trusted, virtual 
transaction/distribution management environment. If, gen- 
erally speaking, certain key functions were generally or 
frequently missing, at least in general purpose VDE node 
electronic appliances 600, then a variety of different prod- 
ucts and different standards would come forth to satisfy the 
wide range of applications for electronic transaction/ 
distribution management; a single consistent set of tools and 
a single "rational," trusted security and commercial distri- 
bution environment will not have been put in place to answer 
the pressing needs of the evolving "electronic highway." 
Certain forms of certain electronic appliances 600 contain- 
ing VDE nodes which incorporate embedded dedicated 
VDE microcontrollers such as certain forms of video cas- 
sette players, cable television converters and the like may 
not necessarily have or need full VDE capabilities. 
However, the preferred embodiment provides a number of 
distributed, disparately located electronic appliances 600 
each of which desirably include authoring, distribution, 
extraction, audit, and audit reduction capabilities, along with 
object authoring capabilities. 

The VDE object authoring capabilities provided by the 
preferred embodiment provides an author, for example, with 
a variety of menus for incorporating methods in a VDE 
object 300, including: 

menus for metering and/or billing methods which define 
how usage of the content portion of a VDE object is to 
be controlled, 

menus related to extraction methods for limiting and/or 
enabling users of a VDE object from extracting infor- 
mation from that object, and may include placing such 
information in a newly created and/or pre-existing 
VDE content container, 
menus for specifying audit methods — that is, whether or 
not certain audit information is to be generated and 
communicated in some secure fashion back to an object 
provider, object creator, administrator, and/or 
clearinghouse, and 
menus for distribution methods for controlling how an 
object is distributed, including for example, controlling 
distribution rights of different participant's "down" a 
VDE chain of content container handling. 
The authoring capabilities may also include procedures for 
distributing administrative budgets, object distribution con- 
trol keys, and audit control keys to distributors and other 
VDE participants who are authorized to perform distribution 
and/or auditing functions on behalf of the author, 
distributors, and/or themselves The authoring capabilities 
may also include procedures for selecting and distributing 
distribution methods, audit methods and audit reduction 
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methods, including for example, securely writing and/or ensure audit information is gathered and/or provided to, in 

otherwise controlling budgets for object redistribution by a proper manner, said additional party. For example, 

distributors to subsequent VDE chain of content handling employing specification information provided by said other 

participants. party. 

The content of an object 300 created by an author may be 5 ^ t . ^ 
generated with the assistance of a VDE aware application 0b J ect CreaUon and In,Ual Contro1 Structures 
program or a non-VDE aware application program. The The VDE preferred embodiment object creation and con- 
content of the object created by an author in conjunction trol structure design processes support fundamental config- 
with such programs may include text, formatted text, urability of control information. Triis enables VDE 100 to 
pictures, moving pictures, sounds, computer software, 10 support a full range of possible content types, distribution 
multimedia, electronic games, electronic training materials, pathways, usage control information, auditing requirements, 
various types of files, and so on, without limitation. The and users and user groups. VDE object creation in the 
authoring process may encapsulate content generated by the preferred embodiment employs VDE templates whose 
author in an object, encrypt the content with one or more atomic elements represent at least in part modular control 
keys, and append one or more methods to define parameters 15 processes. Employing VDE creation software (in the pre- 
of allowed use and/or required auditing of use and/or ferred embodiment a GUI programming process) and VDE 
payment for use of the object by users (and/or by authorized templates, users may create VDE objects 300 by, for 
users only). The authoring process may also include some or example, partitioning the objects, placing "meta data" (e.g., 
all aspects of distributing the object. In general, in the author's name, creation date, etc.) into them, and assigning 
preferred embodiment, an author can: 20 rights associated with them and/or object content to, for 

A. Specify what content is to be included in an object. example, a publisher and/or content creator. When an object 

B. Specify content oriented methods including: creator runs through this process, she normally will go 
Information — typically abstract, promotional, through a content specification procedure which will request 

identifying, scheduling, and/or other information related to required data. The content specification process, when 

the content and/or author 25 satisfied, may proceed by, for example, inserting data into a 

Content — e.g. list of files and/or other information template and encapsulating the content. In addition, in the 

resources containing content, time variables, etc. preferred embodiment, an object may also automatically 

C. Specify control information (typically a collection of register its presence with the local VDE node electronic 
methods related to one another by one or more permissions appliance 600 secure subsystem, and at least one permis- 
records, including any method defining variables) and any 30 sions record 808 may be produced as a result of the 
initial authorized user list including, for example: interaction of template instructions and atomic methods, as 

Control information over Access & Extraction well as one or more pieces of control structure which can 

Control information over Distribution include one or more methods, budgets, and/or etc. A regis- 

Control information over Audit Processing tration process may require a budget to be created for the 

A VDE node electronic appliance 600 may, for example, 35 object. If an object creation process specifies an initial 

distribute an object on behalf of an object provider if a VDE distribution, an administrative object may also be created for 

node receives from an object provider administrative budget distribution. The administrative object may contain one or 

information for distributing the object and associated distri- more permission records 808, other control structures, 

button key information. methods, and/or load modules. 

A VDE node electronic appliance 600 may receive and 40 Permissions records 808 may specify various control 
process audit records on behalf of an object provider if that relationships between objects and users. For example, VDE 
VDE node receives any necessary administrative budget, 100 supports both single access (e.g., one-to-one relation- 
audit method, and audit key information (used, for example, ship between a user and a right user) and group access (any 
to decrypt audit trails), from the object provider. An number of people may be authorized as a group). A single 
auditing-capable VDE electronic appliance 600 may control 45 permissions record 808 can define both single and group 
execution of audit reduction methods. "Audit reduction" in access VDE 100 may provide "sharing" a process that 
the preferred embodiment is the process of extracting infer- allows multiple users to share a single control budget as a 
mation from audit records and/or processes that an object budget. Additional control structure concepts include 
provider (e.g., any object provider along a chain of handling distribution, redistribution, and audit, the latter supporting 
of the object) has specified to be reported to an object's 50 meter and budget information reduction and/or transfer. All 
distributors, object creators, client administrators, and/or 0 f these processes are normally securely controlled by one 
any other user of audit information. This may include, for 0 r more VDE secure subsystems, 
example, advertisers who may be required to pay for a user's 

usage of object content. In one embodiment, for example, a Templates and Classes 

clearinghouse can have the ability to "append" budget, audit 55 VDE templates, classes, and flexible control structures 

method, and/or audit key information to an object or class or support frameworks for organizations and individuals that 

other grouping of objects located at a user site or located at create, modify, market, distribute, redistribute, consume, 

an object provider site to ensure that desired audit processes and otherwise use movies, audio recordings and live 

will take place in a "trusted" fashion. A participant in a chain performances, magazines, telephony based retail sales, 

of handling of a VDE content container and/or content 60 catalogs, computer software, information databases, 

container control information object may act as a "proxy** multimedia, commercial communications, advertisements, 

for another party in a chain of handling of usage auditing market surveys, infomercials, games, CAD/CAM services 

information related to usage of object content (for example for numerically controlled machines, and the like. As the 

a clearinghouse, an advertiser, or a party interested in market context surrounding these classes changes or evolves, the 

survey and/or specific customer usage information). This 65 templates provided by the preferred embodiment of the 

may be done by specifying, for that other party, budget, audit present invention can be modified to meet these changes for 

method, and/or key information that may be necessary to broad use, or more focused activities. 
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VDE 100 authoring may provide Ihree inputs into a create 
process: Templates, user input and object content. Templates 
act as a set of control instructions and/or data for object 
control software which are capable of creating (and/or 
modifying) VDE objects in a process that interacts with user 
instructions and provided content to create a VDE object. 
Templates are usually specifically associated with object 
creation and/or control structures. Classes represent user 
groups which can include "natural" groups within an 
organization, such as department members, specific security 
clearance levels, etc., or ad hoc lists of individual's and/or 
VDE nodes. 

For example, templates may be represented as text files 
defining specific structures and/or component assemblies. 
Templates, with their structures and/or component assem- 
blies may serve as VDE object authoring or object control 
applications A creation template may consist of a number of 
sub-templates, which, at the lowest level, represent an 
"atomic level** of description of object specification. Tem- 
plates may present one or more models that describe various 
aspects of a content object and how the object should be 
created including employing secure atomic methods that are 
used to create, alter, and/or destroy permissions records 808 
and/or associated budgets, etc. 

Templates, classes (including user groups employing an 
object under group access), and flexible control structures 
including object "independent" permissions records 
(permissions that can be associated with a plurality of 
objects) and structures that support budgeting and auditing 
as separate VDE processes, help focus the flexible and 
configurable capabilities inherent within authoring provided 
by the present invention in the context of specific industries 
and/or businesses and/or applications. VDE rationalizes and 
encompasses distribution scenarios currently employed in a 
wide array of powerful industries (in part through the use of 
application or industry specific templates). Therefore, it is 
important to provide a framework of operation and/or struc- 
ture to allow existing industries and/or applications and/or 
businesses to manipulate familiar concepts related to content 
types, distribution approaches, pricing mechanisms, user 
interactions with content and/or related administrative 
activities, budgets, and the like. 

The VDE templates, classes, and control structures are 
inherently flexible and configurable to reflect the breadth of 
information distribution and secure storage requirements, to 
allow for efficient adaptation into new industries as they 
evolve, and to reflect the evolution and/or change of an 
existing industry and/or business, as well as to support one 
or more groups of users who may be associated with certain 
permissions and/or budgets and object types. The flexibility 
of VDE templates, classes, and basic control structures is 
enhanced through the use of VDE aggregate and control 
methods which have a compound, conditional process 
impact on object control. Taken together, and employed at 
times with VDE administrative objects and VDE security 
arrangements and processes, the present invention truly 
achieves a content control and auditing architecture that can 
be configured to most any commercial distribution embodi- 
ment. Thus, the present invention fully supports the require- 
ments and biases of content providers without forcing them 
to fit a predefined application model. It allows them to define 
the rights, control information, and flow of their content (and 
the return of audit information) through distribution chan- 
nels. 

Modifying Object Content (Adding, Hiding, 
Modifying, Removing, and/or Extending) 

Adding new content to objects is an important aspect of 
authoring provided by the present invention. Providers may 
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wish to allow one or more users to add, hide, modify, remove 
and/or extend content that they provide. In this way, other 
users may add value to, alter for a new purpose, maintain, 
and/or otherwise change, existing content. The ability to add 
content to an empty and/or newly created object is important 
as well. 

When a provider provides content and accompanying 
control information, she may elect to add control informa- 
tion that enables and/or limits the addition, modification, 
hiding and/or deletion of said content. This control infor- 
mation may concern: 

the nature and/or location of content that may be added, 
hidden, modified, and/or deleted; 

portions of content that may be modified, hidden, deleted 
and/or added to; 

required secure control information over subsequent VDE 
container content usage in a chain of control and/or 
locally to added, hidden, and/or modified content; 

requirements that provider-specified notices and/or por- 
tions of content accompany added, bidden, deleted 
and/or modified content and/or the fact that said 
adding, hiding, modification and/or deletion occurred; 

secure management of limitations and/or requirements 
concerning content that may be removed, hidden and/or 
deleted from content, including the amount and/or 
degree of addition, hiding, modification and/or deletion 
of content; 

providing notice to a provider or providers that 
modification, hiding, addition and/or deletion has 
occurred and/or the nature of said occurrence; and 

other control information concerned with modification, 
addition, hiding, and/or deleting provider content. 

A provider may use this control information to establish 
an opportunity for other users to add value to and/or main- 
tain existing content in a controlled way. For example, a 
provider of software development tools may allow other 
users to add commentary and/or similar and/or complemen- 
tary tools to their provided objects. A provider of movies 
may allow commentary and/or promotional materials to be 
added to their materials. A provider of CAD/CAM specifi- 
cations to machine tool owners may allow other users to 
modify objects containing instructions associated with a 
specification to improve and/or translate said instructions for 
use with their equipment. A database owner may allow other 
users to add and/or remove records from a provided database 
object to allow flexibility and/or maintenance of the data- 
base. 

Another benefit of introducing control information is the 
opportunity for a provider to allow other users to alter 
content for a new purpose. A provider may allow other users 
to provide content in a new setting. 

To attach this control information to content, a provider 
may be provided with, or if allowed, design and implement, 
a method or methods for an object that govern addition, 
hiding, modification and/or deletion of content. Design and 
implementation of such one or more methods may be 
performed using VDE software tools in combination with a 
FFE 650. The provider may then attach the method(s) to an 
object and/or provide them separately. A permissions record 
808 may include requirements associated with this control 
information in combination with other control information, 
or a separate permissions record 808 may be used. 

An important aspect of adding or modifying content is the 
choice of encryption/decryption keys and/or other relevant 
aspects of securing new or altered content. The provider may 
specify in their mclhod(s) associated with these processes a 
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technique or techniques to be used for- creating and/or correspond to activities initiated by either the system or a 

selecting the encryption/decryption keys and/or other rel- user that correspond to potentially protected processes 

cvant aspect of securing new and/or altered content. For within VDE. These processes include activities such as 

example, the provider may include a collection of keys, a copying a permissions record, copying a budget, reading an 

technique for generating new keys, a reference to a load 5 audit trail record, copying a method, updating a budget, 

module that will generate keys, a protocol for securing updating a permissions record, updating a method, backing 

content, and/or other similar information. up management files, restoring management files, and the 

Another important implication is the management of new ^ Readin „ writing, modifying, updating, processing, 

keys, if any are created and/or used. A provider may require and/of ddetin information from any ^on of any VDE 

that such keys and reference ;to which keys were used must 1Q be administrative events> ^ adm inistrative 

be transmitted to the provider, or she may allow the teys eyent ^ ^ one of moTC f 

and/or securing strategy to remain outside a provider s f ' f . , r . . r . - 

knowledge and/or control. A provider may also choose an thcaforemcnUoncdacUviUcsononcormoreport.onsofone 

intermediate course in which some keys must be transmitted or more rcco 

and others may remain outside her knowledge and/or con- When a VDE electronic appliance 600 encounters an 

trol. 15 administrative event, that event is typically processed in 

An additional aspect related to the management of keys is conjunction with a VDE PPE 650. As in the case of events 

the management of permissions associated with an object generally related to access and/or use of content, in most 

resulting from the addition, hiding, modification and/or cases administrative events are specified by content provid- 

deletion of content A provider may or may not allow a VDE ers (including, for example, content creators, distributors, 

chain of control information user to take some or all of the 20 and/or client administrators) as an aspect of a control 

VDE rules and control information associated with granting specified for an object, group and/or class of objects, 

permissions to access and/or manipulate VDE managed p or example, if a user initiates a request to distribute 

content and/or rules and control information associated with permission to use a certain object from a desktop computer 

said resulting object. For example, a provider may allow a t0 a DO t e book computer, one of the administrative events 

first user to control access to new content in an object, 25 generated may ^ to crea te a copy of a permissions record 

thereby requiring any other user of that portion of content to mat corresponds to the object. When this administrative 

receive permission from the first user. This may or may not, event ^ detected by ROS 602, an EVENT method for this 

at the provider's discretion, obviate the need for a user to l y pe c f evenl may be present. If an EVENT method is 

obtain permission from the provider to access the object at present, there may also be a meter, a billing, and a budget 

a U- 30 associated with the EVENT method. Metering, billing, and 

Keys associated with addition, modification, hiding and/ budgeting can allow a provider to enable and limit the 

or deletion may be stored in an independent permissions copying of a permissions record 808. 

record or records 808. Said permissions record(s) 808 may For 6 te durin the muTSC of processing a control 

be delivered to a provider or providers and potentially prog ram, a meter, a biUing, and a budget and/or audit records 

merged with an existing permissions record or records, or 35 ^ raled and/or updated ^ audU rccords may 

may remain solely under the control of the new content record informatio n concerning circumstances surrounding 

provider. The creation and content of an initial permissions an adminislrative eve nt and processing of said event. For 

record 808 and any control information over the permissions cxampk arj audit record may contain a reference to a user 

record(s) are controlled by the methods) associated with and/or ffl ^ ^ initiated aQ event> (he success or 

activities by a provider. Subsequent modification and/or use 40 Qf ^ eycntj me dale and/or time> arjd/or 

of said permission record(s) may involve a provider s oth er relevant information. 

methodfs), user action, or both. A user's ability to modify _ _ . t . , . - . . • • 

^ J . . v « AO . . j . * Refemne to the above example of a user with both a 

and/or use permissions recordfs) 808 is dependent on, at , . j . . . . -j c 

. t . . . ■ . * i f - - » »L. desktop and notebook computer, the provider of a permis- 

least in part, the senior control information associated with . r . - _•• . . . . 

. .7 _j/ \ f -J At: sions record may require an audit record each time a meter 

the permissions rccordfs) of a provider. 45 -/ * . - , rn _ 

r v / r f or CO py in g j^nj permissions record is processed. The audit 

Distribution Control information record provides a flexible and configurable control and/or 

To enable a broad and flexible commercial transaction recording environment option for a provider. 

environment, providers should have the ability to establish In some circumstances, it may be desirable for a provider 

firm control information over a distribution process without so to limit which aspects of a control component may be 

unduly limiting the possibilities of subsequent parties in a modified, updated, and/or deleted. "Atomic element defini- 

chain of control. The distribution control information pro- tions" may be used to limit the applicability of events (and 

vided by the present invention allow flexible positive con- therefore the remainder of a control process, if one exists) to 

trol. No provider is required to include any particular certain "atomic elements" of a control component. For 

control, or use any particular strategy, except as required by 55 example, if a permissions record 808 is decomposed into 

senior control information. Rather, the present invention "atomic elements" on the fields described in FIG. 26, an 

allows a provider to select from generic control components event processing chain may be limited, for example, to a 

(which may be provided as a subset of components appro- certain number of modifications of expiration date/time 

priatc to a provider's specific market, for example, as information by specifying only this field in an atomic 

included in and/or directly compatible with, a VDE 60 element definition. In another example, a perm Lssions record 

application) to establish a structure appropriate for a given 808 may be decomposed into atomic elements based on 

chain of handling/control. A provider may also establish control sets. In this example, an event chain may be limited 

control information on their control information that enable to events that act upon certain control sets. 

and limit modifications to their control information by other In some circumstances, it may be desirable for a provider 

users. 65 to control how administrative processes are performed. The 

The administrative systems provided by the present provider may choose to include in distribution records stored 

invention generate administrative "events." These "events" in secure database 610 information for use in conjunction 
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with a component assembly 690 that controls and specifies, An example of the process steps used for the move of a 

for example, how processing for a given event in relation to budget record might look something like this: 

a given method and/or record should be performed. For 1) Check the move budget (e.g., to determine the number of 

example, if a provider wishes to allow a user to make copies moves allowed) 

of a permissions record 808, she may want to alter the 5 2) Copy static fields to new record (e.g., as an encumbrance) 

permissions record internally. For example, in the earlier 3 ) Decrement tbe Deer counter in the old record (the original 

example of a user with a desktop and a notebook computer, budget) 

a provider may allow a user to make copies^of information 4) Increment ^ Encumbrance counter in the old record 

necessary to enable the notebook computer based on mfor- 5) wrfte a distribution record 

mation present in the desktop computer, but not aUow any 1Q wrfte a Distribution EveDt Id tQ tne ^ fecord 

further copies of said information to be made by the note- _( f 4 4 , 

book VDE node. In this example, the distribution control 7> ^ement the move meter 

structure described earlier would continue to exist on the g ?*™ovc budget 

desktopcomputer,butthecopiesoftheenabling information 9 ) Increment the Deer counter in the new record 

passed to the notebook computer would lack the required n 

distribution control structure to perform distribution from 15 Creating a Budget 

the notebook computer. Similarly, a distribution control i n tne prc ferred embodiment, to create a budget, a user 

structure may be provided by a content provider to a content manipulates a Graphical User Interface budget distribution 

provider who is a distributor in which a control structure appu cation (e.g., a VDE template application). The user fills 

would enable a certain number of copies to be made of a QUt ^ fields for (s) of bud expiration 

\^E content container objecl t along with associated copies 20 ^ auditor(s)) etc A bud t ^ s ^ fied m 

of permissions records but the permissions records would deutsche m ^ {n ^ mODeta 

be altered (as per specification of the content provider, for Qr measureinent ^ and/or organiza u on . The 

example) so as not to allow end-users who received dis- ferre(J em5odiment output of the app i ication , norma n y 

tributor created copies from making further copies for ^ three basic elements A notadon jn lhe ^nbuiion 

distnbution to other VDE nodes. 25 poftion of database 610 fof each budget fecord 

Although the preceding example focuses on one particular created> the actual budget records, and a method option 

event (copying) under one possible case, similar processes record for illusion in a permissions record. Under some 

may be used for reading, writing, modifying, updating, circumstances, a budget process may not result in the 

processing, and/or deleting information from records and/or creation 0 f a me thod option since an existing method option 

methods under any control relationship contemplated by the 30 may ^ used Normally> all of mis output Ls protected 

present invention. Other examples include: copying a by storage m fo t3Lb3SC 610 and/or m one or more 

budget, copying a meter, updating a budget, updating a administrative objects. 

meter, condensing an audit trail, and the like. ™ , . , c *• #• » , . 

& There are two basic modes of operation for a budget 

Creating Custom Methods 35 distribution application in the preferred embodiment. In the 

In the preferred embodiment of the present invention, first case, the operator has an unlimited ability to specify 

methods may be created "at will," or aliased to another budgets, lhe budgets resulting from this type of activity may 

method. These two modes contribute to the superior be freely used to control any aspect of a distribution process 

configurability, flexibility, and positive control of the VDE for which an operator has rights, including for use with 

distribution process. Generally, creating a method involves 40 "security" budgets such as quantities limiting some aspect of 

specifying the required attributes or parameters for the data For example, if the operator is a "regular person," he 

portion of the method, and then "typing" the method. The ma Y these budgets to control his own utilization of 

typing process typically involves choosing one or more load <*j«*> bascd on a personal accounting model or schedule. 

modules to process any data portions of a method. In ^ the operator is an authorized user at VISA, the resulting 

addition to the method itself, the process of method creation 45 bud £ets may have broad implications for an entire distribu- 

may also result in a method option subrecord for inclusion system. A core idea is that this mode is controlled 

in, or modification of, a permissions record, and a notation strictly by an operator. 

in the distribution records. In addition to any "standard" load The second mode of operation is used to create "alias" 
module(s) required for exercise of the method, additional budgets. These budgets are coupled to a preexisting budget 
load modules, and data for use with those load modules, may 50 in an operator's system. When an operator fills a budget, an 
be specified if allowed. These event processing structures encumbrance is created on the aliased budget. When these 
control the distribution of the method. types of budgets are created, the output includes two method 
For example, consider the case of a security budget. One option subrccords coupled together the method option sub- 
form of a typical budget might limit the user to 10 Mb of record for the aliased budget, and a method option subrecord 
decrypted data per month. The user wishes to move their 55 for the newly created budget. In most cases, the alias budget 
rights to use the relevant VDE content container object to can be used in place of the original budget if the budget 
their notebook. The budget creator might have limited the creator is authorized to modify the method options within 
notebook to the same amount, half the original amount, a the appropriate required method record of a permissions 
prorated amount based on the number of moves budgeted for record . 

an object, etc. A distribute method (or internal event pro- 60 For example, assume that a user (client administrator) at 

cessing structure) associated with the budget allows the a company has the company's VISA budget on her elec- 

creator of the budget to make a determination as to the tronic appliance 600. She wants to distribute budget to a 

methodology and parameters involved. Of course, different network of company users with a variety of preexisting 

distribution methods may be required for the case of budgets and requirements. She also wants to limit use of the 

redistribution, or formal distribution of the method. The 65 company's VISA budget to certain objects. To do this, she 

aggregate of these choices is stored in a permissions record aliases a company budget to the VISA budget. She then 

for the method. modifies (if so authorized) the permissions record for all 
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objects that the company will allow their users to manipulate budgets, etc. These users have do knowledge of, or access to, 

so that they recognize the company budget in addition to, or the clearinghouse (or and/or distributor) accounts of the 

instead of, the VISA budget. She then distributes the new redistributor. The redistributor serves as an auditor for the 

permissions records and budgets to her users. The audit data rights and/or budgets, etc. that they redistribute, unless 

from these users is then reduced against the encumbrance on 5 specifically overridden by restrictions from distributors and/ 

the company's VISA budget to produce a periodic billing. or clearinghouses. Since redistributees (recipients of redis- 

In another example, a consumer wants to control his tributed rights and/or budgets, etc.) would place a relatively 

family's electronic appliance use of his VISA card, and unquantifiable workload on clearinghouses, and 

prevent his children from playing too many video games, furthermore, since a redistributor would be placing himself 

while allowing unlimited use of encyclopedias. In this case, 10 at an auditable risk (responsible for all redistributed rights 

he could create two budgets. The first budget can be aliased and/or budgets, etc.), the audit of rights, budgets, etc. of 

to his VISA card, and might only be used with encyclopedia redistributees by rcdistributors is assumed as the default case 

objects (referenced to individual encyclopedia objects and/ in the preferred embodiment, 

or to one or more classes of encyclopedia objects) that Distribution 

reference the aliased budget in their explicitly modified is Distribution involves three types of entity. Creators usu- 
permissions record. The second budget could be, for ally are the source of distribution. They typically set the 
example, a time budget that he redistributes to the family for control structure "context" and can control the rights which 
use with video game objects (video game class). In this are passed into a distribution network. Distributors are users 
instance, the second budget is a "self -replenishing" security/ who form a link between object (content) end users and 
control budget, that allows, for example, two hours of use 20 object (content) creators. They can provide a two-way 
per day. The first budget operates in the same manner as the conduit for rights and audit data. Clearinghouses may pro- 
earlier example. The second budget is added as a new vide independent financial services, such as credit and/or 
required method to permissions records for video games. billing services, and can serve as distributors and/or creators. 
Since the time budget is required to access the video games, Through a permissions and budgeting process, these parties 
an effective control path is introduced for requiring the 25 collectively can establish fine control over the type and 
second budget — only permissions records modified to extent of rights usage and/or auditing activities, 
accept the family budget can be used by the children for Encumbrance 

video games and they are limited to two hours per day. Aq « encumbrance ~ ^ a special type of VDE budget. 

Sharing and Distributing Rights and Budgets 30 When that a budget distribution of any type occurs, an 

"encumbrance" may be generated. An encumbrance is indis- 

ovc tinguishable from an original budget for right exercise (e.g., 

The VDE "move" concept provided by the preferred content usage payment) purposes, but is uniquely identified 

embodiment covers the case of "friendly sharing** of rights within distribution records as to the amount of the 

and budgets. A typical case of "move" is a user who owns encumbrance, and all necessary information to complete a 

several machines and wishes to use the same objects on shipping record to track the whereabouts of an encumbrance, 

more than one of them. For example, a user owns a desktop p or rignt exercise purposes, an encumbrance is identical to 

and a notebook computer. They have a subscription to an an original budget; but for tracking purposes, it is uniquely 

electronic newspaper that they wish to read on either identifiable. 

machine, i.e the user wishes to move rights from one ^ , n me prefeired embodiment of the present invention, a 

machine to the other. Distribution Event ID will be used by user VDE nodes and 

An important concept within "move" is the idea of by clearinghouse services to track and reconcile 

independent operation. Any electronic appliance 600 to encumbrances, even in the case of asynchronous audits. That 

which rights have been moved may contact distributors or ^ lhe « new >* encumbrance budget is unique from a tracking 

clearinghouses independently. For example, the user men- ^ 0 f vj ew> but indistinguishable from a usage point of 

tioned above may want to take their notebook on the road for view. 

an extended period of time and contact clearinghouses and Unresolved encumbrances are a good intermediate con- 

distnbutors without a local connection to their desktop. ^ fof a yDE distribution process . A citable "grace 

To support independent operation, the user should be able period" can be introduced during which encumbrances must 

to define an account with a distributor or clearinghouse that 5Q be resolved. If this period elapses, an actual billing or 

is independent of the electronic appliance 600 she is using payment may occur. However, even after the interval has 

to connect. The transactions must be independently trace- expired and the billing and/or payment made, an encum- 

able and reconcilable among and between machines for both brance may still be outstanding and support later reconcili- 

the end user and the clearinghouse or distributor. The basic at i on j n c^ ^ auditor may allow a user to gain a 

operations of moving rights, budgets, and bitmap or com- 55 cre di t , or a user may connect to a VDE node containing an 

pound meters between machines is also supported. encumbered budget, and resolve an amount as an internal 

Redistribution credit. In some cases, missing audit trails may concern a 

Redistribution forms a UDE middle ground between the distributor sufficiently to revoke redistribution privileges if 

"friendly sharing" of "move," and formal distribution. encumbrances arc not resolved within a "grace period," or if 

Redistribution can be thought of as "anonymous distribu- 60 there arc repeated grace period violations or if unresolved 

lion" in the sense that no special interaction is required encumbrances are excessively large, 

between a creator, clearinghouse, or distributor and a redis- Encumbrances can be used across a wide variety of 

tributor. Of course, a creator or distributor does have the distribution modes. Encumbrances, when used in concert 

ability to limit or prevent redistribution. with aliasing of budgets, opens important additional distri- 

Unl ike the "move" concept, redistribution does not imply 65 bution possibilities. In the case of aliasing a budget, the user 

independent operation. The redistributor serves as one point places himself in the control path for an object — an aliased 

of contact for users receiving redistributed rights and/or budget may only be used in conjunction with permissions 
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records that have been modified to recognize it. An eocum- Passing an Audit 

brance has no such restrictions. Iq ^ prcfcfTcd cmbodimcnt of VDE there may be at least 

For example, a user may want to restrict his children's use two lypcs of auditing. I n the case of budget distribution, 

of his electronic, VDE node VISA budget. In this case, the bming reconJs mat reflect consumption 0 f a budget gener- 

user can generate an encumbrance on his VISA budget for 5 aUy Qeed (Q ^ and processe d. In the case of 

the children's family alias budget, and another for his wife permissions distribution, usage data associated with an 

that is a transparent encumbrance of the original VISA ob j ecl m aLso f reqU ently required, 

budget. BigCo may use a similar mechanism to distribute . * 4 

.„Zr A . ■ * . ' »uj j r jdt k j , I" 0fl d er to effect control over an object, a creator may 

VISA budget to department heads, and aliased BigCo budget 4 ... . . . . , , . . . J . 4 , 4U 

» ■ -i in establish the basic control information associated with an 
to users directly 

J " object. This is done in the formulation of permissions, the 

Account Numbers and User IDs distribution of various security, administrative and/or finan- 

In the preferred embodiment, to control access to cial budgets, and the level of redistribution that is allowed, 

clearinghouses, users are assigned account numbers at clear- etc - Distributors (and redistributors) may further control this 

inghouses. Account numbers provide a unique "instance" 15 me bud S ets - etc * 

value for a secure database record from the point of view of information) they have received. 

an outsider. From the point of view of an electronic appli- For example, an object creator may specify that additional 

ance 600 site, the user, group, or group/user ids provide the required methods may be added freely to their permissions 

unique instance of a record. For example, from the point of records, establish no budget for this activity, and allow 

view of VISA, your Gold Card belongs to account number 20 unlimited redistribution of this right. As an alternative 

#123456789. From the point of view of the electronic example, a creator may allow moving of usage rights by a 

appliance site (for example, a server at a corporation), the distributor to half a dozen subdistributors, each of whom can 

Gold card might belong to user id 1023. In organizations distribute 10,000 copies, but with no redistribution rights 

which have plural users and/or user groups using a VDE being allowed to be allocated to subdistributors* 

node, such users and/or user groups will likely be assigned 25 (redistributors*) customers. As another example, a creator 

unique user IDs. differing budgets and/or other user rights may authorize the moving of usage rights to only 10 VDE 

may be assigned to different users and/or user groups and/or nodes, and to only one level of distribution (no 

other VDE control information may be applied on a differing redistribution). Content providers and other contributors of 

manner to electronic content and/or appliance usage by users control information have the ability through the use of 

assigned with different such IDs. Of course, both a clear- 30 permissions records and/or component assemblies to control 

inghouse and a local site will likely have both pieces of rights other users are authorized to delegate in the permis- 

information, but "used data" versus the "comment data" sions records they send to those users, so long as such right 

may differ based on perspective. 10 control one, some, or all such rights of other users is either 

In the preferred embodiment case of "move," an account permitted or restricted (depending on the control informa- 

number stored with rights stays the same. In the preferred 35 tion distribution model). It is possible and often desirable, 

embodiment of other forms of distribution, a new account VDE > t0 construct a mixed model in which a distribu- 

number is required for a distributee. This may be generated lor * restricted from controlling certain rights of subsequent 

automatically by the system, or correspond to a methodol- and » aUowed to conlrol other ri Sl** VDE of 

ogy developed by a distributor or redistributor. Distributors distribution in some VDE models will in part or 

maintain account numbers (and associated access secrets) in 40 whole, at least for certain one or more "levels" of a distn- 

their local name services for each distributee. Conversely, bution chain > be controlled by electronic content control 

distributees' name services may store account numbers information providers who are either not also providers of 

based on user id for each distributor. This record usually is the related or P^vide only a portion of the content 

moved with other records in the case of move, or is controlled by said content control information. For example, 

generated during other forms of distribution. 45 in certain models, a clearinghouse might also serve as a 

Organizations (including families) may automatically ^ distribution agent who provides one or more rights to 

assign unique user IDs when creating control information certa ^ ^ ?™ P artlc 'P ants > which one or more rights 

, n ' , J r o „ cpr „ t ° may be "attached to one or more rights to use the clear- 

(e.g., a budget) for a new user or user group. J . & . 

inghouse s credit (if said clearinghouse is, at least in part, a 

Requirements Record so financial clearinghouse (such a control information provider 

In order to establish the requirements, and potentially may alternatively, or in addition, restrict other users' rights, 

options, for exercising a right associated with a VDE content A content creator or other content control information 

container object before one or more required permissions provider may budget a user (such as a distributor) to create 

records are received for that object, a requirements record an unlimited number of permissions records for a content 

may exist in the private header of such an object. This record 55 object, but revoke this right and/or other important usage 

will help the user establish what they have, and what they rights through an expiration/termination process if the user 

need from a distributor prior to forming a connection. If the does not report his usage (provide an audit report) at some 

requirements or possibilities for exercising a particular right expected one or more points in time and/or after a certain 

have changed since such an object was published, a modified interval of time (and/or if the user fails to pay for his usage 

requirements record may be included in a container with an 60 or violates other aspects of the agreement between the user 

object (if available and allowed), or a new requirements and the content provider). This termination (or suspension or 

record may be requested from a distributor before registra- other specified consequence) can be enforced, for example, 

tion is initiated. Distributors may maintain "catalogs" by the expiration of lime-aged encryption keys which were 

online, and/or delivered to users, of collections of require- employed to encrypt one or more aspects of control in for- 

ments records and/or descriptive information corresponding 65 ma tion. This same termination (or other specified conse- 

to objects for which they may have ability to obtain and/or quence such as budget reduction, price increase, message 

grant rights to other users. displays on screen to users, messages to administrators, etc.) 
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can also be the consequence of the failure by a user or the audit information to be passed back to it, for example, after 
users VDE installation to complete a monitored process, every 50,000 audit records are processed (or any other unit 
such as paying for usage in electronic currency, failure to of quantity and/or after a certain time interval and/or at a 
perform backups of important stored information (e.g., con- certain predetermined date) by a redistributor. In the pre- 
text and/or appliance usage information, control 5 ferred embodiment, audit rules, like other control structures, 
information, etc.), failure to use a repeated failure to use the ma y 00 stipulated at any stage of a distribution chain of 
proper passwords or other identifiers, etc.). handling as long as the right to stipulate said rules has not 

Generally, the collection of audit information that is be f n "f**? *- "T ^ 

collected for reporting to a certain auditor can be enforced informat.on dLstributmg (such as an auditing) participant, 

by expiration and/or other termination processes. For io Audlt "formation that is destined for different auditors 

example, the user's VDE node may be instructed (a) from an m ^ v ^ encrypted by different one or more encryption keys 

external source to no longer perform certain tasks, (b) carries wn ] ch have bccn securely provided by each auditor's VDE 

within its control structure information informing it to no node md communicated for inclusion in a user's r*rmis- 

longer perform certain tasks, or (c) is elsewise no longer able slons record(s) as a required step, for example, during object 

to perform certain tasks. The certain tasks might comprise is registration. This can provide additional security to further 

one or more enabling operations due to a user's (or ensure Ofy° ad . tbe of Passwords and/or other identifi- 

installation's) failure to either report said audit information catl0n ^formation ™d other VDE security features) that an 

to said auditor and/or receive back a secure confirmation of audltor ma y onlv access audlt information to which he is 

receipt and/or acceptance of said audit information. If an authorized- In one embodiment, encrypted (and/or 

auditor fails to receive audit information from a user (or 20 unencrypted) "packets" of audit information (for example, 

some other event fails to occur or occur properly), one or m *** form of administrative objects) may be bound for 

more time-aged keys which are used, for example, as a duTerent audltors eluding a clearinghouse and/or content 

security component of an embodiment of the present Providers and/or other audit information users (including, 

invention, may have their aging suddenly accelerated for example, market analysts and/or list purveyors). The 

(completed) so that one or more processes related to said 25 information may pass successively through a single chain of 

time-aged keys can no longer be performed. handling, for example, user to clearinghouse to redistributor 

to distributor to publisher/object creator, as specified by 

Authorization Access Tags and VDE audit control structures and parameters. Alternatively, 

Modification Access Tags encrypted (or, normally less preferably, unencrypted) audit 

In order to enable a user VDE installation to pass audit 30 packets may be required to be dispersed direcdy from a user 

information to a VDE auditing party such as a to a plurality of auditors, some one or more who may have 

Clearinghouse, VDE allows a VDE auditing party to the responsibility to "pass along" audit packets to other 

securely, electronically communicate with the user VDE auditors. In another embodiment, audit information may be 

installation and to query said installation for certain or all passed, for example, to a clearinghouse, which may then 

information stored within said installation's secure sub- 35 redistribute all and/or appropriate subsets of said informa- 

system, depending on said auditing party's rights (said party lion (and/or some processed result) to one or more other 

shall normally be unable to access securely stored in forma- parties, said redistribution employing VDE secure objects 

tion that said party is not expressly authorized to access, that created by said clearinghouse. 

is one content provider will normally not be authorized to An important function of an auditor (receiver of audit 

access content usage information related to content provided 40 information) is to pass administrative events back to a user 

by a different content provider). The auditing party asserts a VDE node in acknowledgement that audit information has 

secure secret (e.g., a secure tag) that represents the set of been received and/or "recognized." In the preferred 

rights of the auditor to access certain information maintained embodiment, the receipt and/or acceptance of audit infor- 

by said subsystem. If said subsystem validates said tag, the mation may be followed by two processes. The first event 

auditing party may then receive auditing information that it 45 will cause the audit data at a VDE node which prepared an 

is allowed to request and receive. audit report to be deleted, or compressed into, or added to, 

Great flexibility exists in the enforcement of audit trail one or more summary values. The second event, or set of 

requirements. For example, a creator (or other content events, will "inform" the relevant security (for example, 

provider or control information provider or auditor in an termination and/or other consequence) control information 

object's or audit report's chain of handling) may allow 50 (for example, budgets) at said VDE node of the audit receipt, 

changes by an auditor for event trails, but not allow anyone modify expiration dates, provide key updates, and/or etc. In 

but themselves to read those trails, and limit the redistribu- most cases, these events will be sent immediately to a site 

tion of this right to, for example, six levels. Alternatively, a after an audit trail is received. In some cases, this transmis- 

creator or other controlling party may give a distributor the sion may be delayed to, for example, first allow processing 

right to process, for example, 100,000 audit records (and/or, 55 of the audit trail and/or payment by a user to an auditor or 

for example, the right to process 12 audit records from a other party. 

given user) before reporting their usage. If a creator or other In the preferred embodiment, the administrative events 

controlling party desires, he may allow (and/or require) for content objects and independently distributed methods/ 

separate (and containing different, a subset of, overlapping, component assemblies are similar, but not necessarily iden- 

or the same information) audit "packets" containing audit 60 tical. For example, key updates for a budget may control 

information, certain of said audit information to be pro- encryption of a billing trail, rather than decryption of object 

cessed by a distributor and certain other of said audit content. The billing trail for a budget is in all respects a 

information to be passed back to the creator and/or other method event trail. In one embodiment, this trail must 

auditors (each receiving the same, overlapping, a subset of, include sufficient references into distribution records for 

or different audit information). Similarly, as long as allowed 65 encumbrances to allow reconciliation by a clearinghouse, 

by, for example, an object creator, a distributor (or other This may occur, for example, if a grace period elapses and 

content and/or control information provider) may require the creator of a budget allows unresolved encumbrances to 
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ultimately yield automatic credits if an expired encumbrance 
is "returned" to the creator. 

Delivery of audit reports through a path of handling may 
be in part insured by an inverse (return of information) audit 
method. Many VDE methods have at least two pieces: a 
portion that manages the process of producing audit infor- 
mation at a user's VDE node; and a portion that subse- 
quently acts on audit data. In an example of the handling of 
audit information bound for a plurality of auditors, a single 
container object is received at a clearinghouse (or other 
auditor). This container may contain (a) certain encrypted 
audit information that is for the use of the clearinghouse 
itself, and (b) certain other encrypted audit information 
bound for other one or more auditor parties. The two sets of 
information may have the same, overlapping and in part 
different, or entirely different, information content. 
Alternatively, the clearinghouse VDE node may be able to 
work with some or all of the provided audit information. The 
audit information may be, in part, or whole, in some 
summary and/or analyzed form further processed at the 
clearinghouse and/or may be combined with other informa- 
tion to form a, at least in part, derived set of information and 
inserted into one or more at least in part secure VDE objects 
to be communicated to said one or more (further) auditor 
parties. When an audit information container is securely 
processed at said clearinghouse VDE node by said inverse 
(return) audit method, the clearinghouse VDE node can 
create one or more VDE administrative objects for securely 
carrying audit information to other auditors while separately 
processing the secure audit information that is specified for 
use by said clearinghouse. Secure audit processes and credit 
information distribution between VDE participants normally 
takes place within the secure VDE "black box," that is 
processes are securely processed within secure VDE 
PPE650 and audit information is securely communicated 
between the VDE secure subsystems of vDE participants 
employing VDE secure communication techniques (e.g., 
public key encryption, and authentication). 

This type of inverse audit method may specify the han- 
dling of returned audit information, including, for example, 
the local processing of audit information and/or the secure 
passing along of audit information to one or more auditor 
parties. If audit information is not passed to one or more 
other auditor parties as may be required and according to 
criteria that may have been set by said one or more other 
auditor parties and/or content providers and/or control infor- 
mation providers during a permissions record specification 
and/or modification process, the failure to, for example, 
receive notification of successful transfer of required audit 
information by an auditor parly, e.g., a content provider, can 
result in the disablement of at least some capability of the 
passing through party's VDE node (for example, disable- 
ment of the ability to further perform certain one or more 
VDE managed business functions that are related to object 
(s) associated with said audit or party). In this preferred 
embodiment example, when an object is received by an 
auditor, it is automatically registered and permissions record 
(s) contents arc entered into the secure management data- 
base of the auditor's VDE node. 

One or more permissions records that manage the creation 
and use of an audit report object (and may manage other 
aspects of object use as well) may be received by a user's 
system during an audit information reporting exchange (or 
other electronic interaction between a user and an auditor or 
auditor agent). Each received permissions record may gov- 
ern the creation of the next audit report object. After the 
reporting of audit information, a new permissions record 
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may be required at a user's VDE node to refresh the 
capability of managing audit report creation and audit infor- 
mation transfer for the next audit reporting cycle. In our 
above example, enabling an auditor to supply one or more 

5 permissions records to a user for the purpose of audit 
reporting may require that an auditor (such as a 
clearinghouse) has received certain, specified permissions 
records itself from "upstream" auditors (such as, for 
example, content and/or other content control information 

10 providers). Information provided by these upstream permis- 
sions records may be integrated into the one or more 
permissions records at an auditor VDE (e.g., clearinghouse) 
installation that manage the permissions record creation 
cycle for producing administrative objects containing per- 

15 missions records that are bound for users during the audit 
information reporting exchange. If an upstream auditor fails 
to receive, and/or is unable to process, required audit 
information, this upstream auditor may fail to provide to the 
clearinghouse (in this example) the required permissions 

20 record information which enables a distributor to support the 
next permission record creation/auditing cycle for a given 
one or more objects (or class of objects). As a result, the 
clearinghouse's VDE node may be unable to produce the 
next cycle's permissions records for users, and/or perform 

25 some other important process. This VDE audit reporting 
control process may be entirely electronic process manage- 
ment involving event driven VDE activities at both the 
intended audit information receiver and sender and employ- 
ing both their secure PPE650 and secure VDE communica- 

30 tion techniques. 

In the preferred embodiment, each time a user registers a 
new object with her own VDE node, and/or alternatively, 
with a remote clearinghouse and/or distributor VDE node, 
one or more permissions records are provided to, at least in 

35 part, govern the use of said object. The permissions records 
may be provided dynamically during a secure UDE regis- 
tration process (employing the VDE installation secure 
subsystem), and/or may be provided following an initial 
registration and received at some subsequent time, e.g. 

40 through one or more separate secure VDE communications, 
including, for example, the receipt of a physical arrangement 
containing or otherwise carrying said information. At least 
one process related to the providing of the one or more 
permissions records to a user can trigger a metering event 

45 which results in audit information being created reflecting 
the user's VDE node's, clearinghouse's, and/or distributor's 
permissions records provision process. This metering pro- 
cess may not only record that one or more permissions 
records have been created. It may also record the VDE node 

50 name, user name, associated object identification 
information, time, date, and/or other identification informa- 
tion. Some or all of this information can become part of audit 
information securely reported by a clearinghouse or 
distributor, for example, to an auditing content creator 

55 and/or other content provider. This information can be 
reconciled by secure VDE applications software at a receiv- 
ing auditor's site against a user's audit information passed 
through by said clearinghouse or distributor to said auditor. 
For each metered one or more permissions records (or set of 

60 records) that were created for a certain user (and/or VDE 
node) to manage use of certain one or more VDE object(s) 
and/or to manage the creation of VDE object audit reports, 
it may be desirable that an auditor receive corresponding 
audit information incorporated into an, at least in part, 

65 encrypted audit report. This combination of metering of the 
creation of permissions records; secure, encrypted audit 
information reporting processes; secure VDE subsystem 
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reconciliation of metering information reflecting the ere- which can be described as a VDE controlled process. For 

ation of registration and/or audit reporting permissions with example, simple control information may be associated with 

received audit report detail; and one or more secure VDE viewing the one or more portions of documents and addi- 

installatioo expiration and/or other termination and/or other tional control information may be associated with editing, 

consequence processes; taken together significantly 5 printing and copying the same and/or different one or more 

enhances the integrity of the VDE secure audit reporting portions of these same documents. 

process as a trusted, efficient, commercial environment. In this example, a "client" container contains all docu- 

_ ments that have been provided by the client (documents 

Secure Document Management Example received in other containers can be securely extracted and 

VDE 100 may be used to implement a secure document in embedded into the VDE client container using VDE extrac- 

management environment. The following are some tion and embedding capabilities). Each document in this 

examples of how this can be accomplished. example is stored as an object within the parent, client VDE 

In one example, suppose a law firm wants to use VDE 100 container. The "client** container also has several other 

to manage documents. In this example, a law firm that is part objects embedded within it; one for each attorney to store 

of a litigation team might use VDE in the following ways: 15 their client notes, one (or more) for research results and 

1. to securely control access to, and/or other usage of, related information, and at least one for copies of letters, 
confidential client records, work papers, and briefs that have been created by the law 

2. to securely control access, distribution, and/or other rights firm. The client container may also contain other informa- 
to documents and memoranda created at the law firm, tion about the client, including electronic records of billing, 

3. to securely control access and other use of research 20 time, accounting, and payments. Embedding VDE objects 
materials associated with the case, within a parent VDE content container provides a conve- 

4. to securely control access and other use, including dis- nient way to securely categorize and/or store different infor- 
tribution of records, documents, and notes associated with mation that shares similar control information. All client 
the case, provided documents may, for example, be subject to the 

5. to securely control how other firms in the litigation team 25 same control structures related to use and non-disclosure, 
may use, including change, briefs that have been distrib- Attorney notes may be subject to control information, for 
uted for comment and review, example, their use may be limited to the attorney who 

6. to help manage client billing. created the notes and those attorneys to whom such creating 
The law firm may also use VDE to electronically file briefs attorney expressly grants access rights. Embedded contain- 
with the court (presuming the court is also VDE capable) 30 crs also provide a convenient mechanism to control collec- 
inchiding providing secure audit verification of the ID (e.g., tions of dissimilar information. For example, the research 
digital signature) of filers and other information pertinent to objects) may be stored in the form of (or were derived from) 
said filing procedure. VDE "smart objects'* that contain the results of research 

In this example, the law firm receives in VDE content performed by that object. Research results related to one 

containers documents from their client's VDE installation 35 aspect of the case retrieved from a VDE enabled LEXIS site 

secure subsystem(s). Alternatively, or in addition, the law might be encapsulated as one smart object; the results of 

I firm may receive either physical documents which may be another session related to another (or the same) aspect of the 

J scanned into electronic form, and/or they receive electronic case may be encapsulated as a different object. Smart objects 

/ documents which have not yet been placed in VDE con- are used in this example to help show that completely 

I tainers. The electronic form of a document is stored as a 40 disparate and separately delivered control information may 

/ VDE container (object) associated with the specific client be incorporated into a client container as desired and/or 

and/or case. The VDE container mechanism supports a required to enforce the rights of providers (such as content 

hierarchical ordering scheme for organizing files and other owners). 

information within a container; this mechanism may be used Control structures may be employed to manage any 
to organize the electronic copies of the documents within a 45 variety of desired granularities and/or logical document 
container, A VDE container is associated with specific content groupings; a document, page, paragraph, topically 
access control information and rights that are described in related materials, etc. In this example, the following 
one or more permissions control information sets (PERCs) assumptions are made: client provided documents are con- 
associated with that container. In this example, only those trolled at the page level, attorney notes arc controlled at the 
members of the law firm who possess a VDE instance, an 50 document level on an attorney by attorney basis, court filings 
appropriate PERC, and the VDE object that contains the and briefs arc controlled at a document level, research 
desired document, may use the document. Alternatively or in information is controlled at whatever level the content 
addition, a law firm member may use a VDE instance which provider specifies at the time the research was performed, 
has been installed on the law firm's network server. In this and certain highly confidential information located in vari- 
case, the member must be identified by an appropriate PERC 55 ous of the above content may be identified as subject to 
and have access to the document containing VDE object (in display and adding comments only, and only by the lead 
order to use the server VDE installation). Basic access partner attorneys, with only the creator and/or embedder of 
control to electronic documents is enabled using the secure a given piece of content having the right to be otherwise 
subsystem of one or more user VDE installations. used (printed, extracted, distributed, etc). 

VDE may be used to provide basic usage control in 60 In general, container content in this example is controlled 

several ways. First, it permits the "embedding" of multiple with respect to distribution of rights. This control informa- 

containers within a single object. Embedded objects permit tion are associated at a document level for all internally 

the "nesting" of control structures within a container. VDE generated documents, at a page level for client level 

also extends usage control information to an arbitrary granu- documents, and at the level specified by the content provider 

lar level (as opposed to a file based level provided by 65 for research documents. 

traditional operating systems) and provides flexible control VDE control information can be structured in either 

information over any action associated with the information complex or simple structures, depending on the participant's 
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desires. In some cases, a VDE creator will apply a series of 
control structure definitions that they prefer to use (and that 
are supported by the VDE application managing the speci- 
fication of rules and control information, either directly, or 
through the use of certified application compatible VDE 
component assemblies. 

In this example, the law firm sets up a standard VDE 
client content container for a new client at the time they 
accept the case. A law firm VDE administrator would 
establish a VDE group for the new client and add the VDE 
IDs of the attorneys at the firm that are authorized to work 
on the case, as well as provide, if appropriate, one or more 
user template applications. These templates provide, for 
example, one or more user interfaces and associated control 
structures for selection by users of additional and/or alter- 
native control functions (if allowed by senior control 
information), entry of control parameter data, and/or per- 
forming user specific administrative tasks. The administrator 
uses a creation tool along with a predefined creation tem- 
plate to create the container. This creation template specifies 
the document usage (including distribution control 
information) for documents as described above. Each elec- 
tronic document from the client (including letters, 
memoranda, E-mail, spreadsheet, etc.) are then added to the 
container as separate embedded objects. Each new object is 
created using a creation template that satisfies that the 
default control structures specified with the container as 
required for each new object of a given type. 

As each attorney works on the case, they may enter notes 
into an object stored within the client's VDE container. 
These notes may be taken using a VDE aware word pro- 
cessor already in use at the law firm. In this example, a VDE 
redirector handles the secure mapping of the word processor 
file requests into the VDE container and its objects through 
the use of VDE control processes operating with one or more 
VDE PPEs. Attorney note objects are created using the 
default creation template for the document type with assis- 
tance from the attorney if the type cannot be automatically 
determined from the content. This permits VDE to auto- 
matically detect and protect the notes at the predetermined 
level, e.g. document, page, paragraph. 

Research can be automatically managed using VDE. 
Smart objects can be, used to securely search out, pay for if 
necessary, and retrieve information from VDE enabled 
information resources on the information highway. 

Examples of such resources might include LEXIS, 
Westlaw, and other related legal databases. Once the infor- 
mation is retrieved, it may be securely embedded in the VDE 
content client container. If the smart object still contains 
un released information, the entire smart object may be 
embedded in the client's VDE container. This places the 
un re leased information under double VDE control require- 
ments: those associated with releasing the information from 
smart object (such as payment and/or auditing requirements) 
and those associated with access to, or other usage of, client 
information of the specified type. 

Briefs and other filings may be controlled in a manner 
similar to that for attorney notes. The filings may be edited 
using the standard word processors in the law firm; with 
usage control structures controlling who may review, 
change, and/or add to the document (or, in a more sophis- 
ticated example, a certain portion of said document). VDE 
may also support electronic filing of briefs by providing a 
trusted source for time/date stamping and validation of filed 
documents. 

When the client and attorney want to exchange confiden- 
tial information over electronic mail or other means, VDE 
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can play an important role in ensuring that information 
exchanged under privilege, properly controlled, and not 
inappropriately released and/or otherwise used. The mate- 
rials (content) stored in a VDE content container object will 

5 normally be encrypted. Thus wrapped, a VDE object may be 
distributed to the recipient without fear of unauthorized 
access and/or other use. The one or more authorized users 
who have received an object are the only parties who may 
open that object and view and/or manipulate and/or other- 

10 wise modify its contents and VDE secure auditing ensures a 
record of all such user content activities. VDE also permits 
the revocation of rights to use client/attorney privileged 
information if such action becomes necessary, for example, 
after an administrator review of user usage audit informa- 

15 tion. 

Large Organization Example 

In a somewhat more general example, suppose an orga- 

2Q nization (e.g., a corporation or government department) with 
thousands of employees and numerous offices disposed 
throughout a large geographic area wishes to exercise con- 
trol over distribution of information which belongs to said 
organization (or association). This information may take the 

^ form of formal documents, electronic mail messages, text 
files, multimedia files, etc„ which collectively are referred to 
as "documents." 

Such documents may be handled by people (referred to as 
"users") and/or by computers operating on behalf of users. 

3Q The documents may exist both in electronic form for storage 
and transmission and in paper form for manual handling. 

These documents may originate wholly within the 
organization, or may be created, in whole or in part, from 
information received from outside the organization. Autho- 

35 rized persons within the organization may choose to release 
documents, in whole or in part, to entities outside the 
organization. Some such entities may also employ VDE 100 
for document control, whereas others may not. 

40 Document Control Policies 

The organization as a whole may have a well-defined 
policy for access control to, and/or other usage control of 
documents. This policy may be based on a "lattice model" 
of information flow, in which documents are characterized 

45 as having one or more hierarchical "classification" security 
attributes 9903 and zero or more non-hierarchical "compart- 
ment" security attributes, all of which together comprise a 
sensitivity security attribute. 

5(J The classification attributes may designate the overall 
level of sensitivity of the document as an clement of an 
ordered set. For example, the set "unclassified," 
"confidential," "secret," "top secret" might be appropriate in 
a government setting, and the set "public," "internal," 

5S "confidential," "registered confidential" might be appropri- 
ate in a corporate setting. 

The compartment attributes may designate the docu- 
ment's association with one or more specific activities 
within the organization, such as departmental subdivisions 

60 ( e *S-» "research," "development," "marketing") or specific 
projects within the organization. 

Each person using an electronic appliance 600 would be 
assigned, by an authorized user, a set of permitted sensitivity 
attributes to designate those documents, or one or more 

65 portions of certain document types, which could be pro- 
cessed in certain one or more ways, by the person's elec- 
tronic appliance. A document's sensitivity attribute would 
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have to belong to the user's set of permitted sensitivity appliance 600 to make VDE-protected documents available 

values to be accessible. for use while limiting the extent to which their contents may 

In addition, the organization may desire to permit users to be copied, stored, viewed, modified, and/or transmitted 

exercise control over specific documents for which the user and/or otherwise further distributed outside the specific 

has some defined responsibility. As an example, a user (the 5 electronic appliance. 

"originating user") may wish to place an "originator con- Users may wish to employ commercial, off-the-shelf 

trolled" ("ORCON") restriction on a certain document, such ("COTS") operating systems and application programs to 

that the document may be transmitted and used only by those process the VDE-protected documents. One approach to 

specific other users whom he designates (and only in certain, permit the use of COTS application programs and operating 

expressly authorized ways). Such a restriction may be flex- *° systems would be to allow such use only for documents 

ible if the "distribution list" could be modified after the without restrictions on redistribution. The standard VDE 

creation of the document, specifically in the event of some- operating system redirector would allow users to access 

one requesting permission from the originating user to VDE-protected documents in a manner equivalent to that for 

transmit the document outside the original list of authorized files. In such an approach, however, a chain of control for 

recipients. The originating user may wish to permit distri- 15 metering and/or auditing use may be "broken" to some 

bution only to specific users, defined groups of users, extent at the point that the protected object was made 

defined geographic areas, users authorized to act in specific available to the COTS application. The fingerprinting 

organizational roles, or a combination of any or all such (watermarking) techniques of VDE may be used to facilitate 

attributes. further tracking of any released information. 

In this example, the organization may also desire to 20 A variety of techniques may be used to protect printing of 

permit users to define a weaker distribution restriction such protected documents, such as, for example: server-based 

that access to a document is limited as above, but certain or decryption engines, special fonts for "fingerprinting," etc. 

all information within the document may be extracted and Another approach to supporting COTS software would 

redistributed without further restriction by the recipients. use me VDE software running on the user's electronic 

The organization and/or originating users may wish to 25 appliance to create one or more "virtual machine" environ- 

know to what uses or geographic locations a document has merits in which COTS operating system and application 

been distributed. The organization may wish to know where programs may run, but from which no information may be 

documents with certain protection attributes have been permanently stored or otherwise transmitted except under 

distributed, for example, based on geographic information control of VDE. Such an environment would permit VDE to 

stored in site configuration records and/or name services manage all VDE-protected information, yet may permit 

records. unlimited use of COTS applications to process that infor- 

A user may wish to request a "return receipt" for a mation within the confines of a restricted environment. The 

distributed document, or may wish to receive some indica- entire contents of such an environment could be treated by 

tion of how a document has been handled by its recipients 3S VDE 100 as an extension to any VDE-protected documents 

(e.g., whether it has been viewed, printed, edited and/or read into the environment. Transmission of information out 

stored), for example, by specifying one or more audit of the environment could be governed by the same rules as 

requirements (or methods known to have audit the original documents), 

requirements) in a PERC associated with such document(s). "Coarse-Grain" Control Capabilities 

As mentioned above, an organization may employ VDE- 

Uscr Environment 40 enforced control capabilities to manage the security, 

In an organization (or associateion) such as that described distribution, integrity, and control of entire documents, 

above, users may utilize a variety of electronic appliances S° wc examples of these capabilities may include: 

600 for processing and managing documents. This may 1) A communication channel connecting two or more 

include personal computers, both networked and otherwise, 45 electronic appliances 600 may be assigned a set of 

powerful single-user workstations, and servers or mainframe permitted sensitivity attributes. Only documents whose 

computers. To provide support for the control information sensitivity attributes belong to this set would be per- 

described in this example, each electronic appliance that m it ted to be transmitted over the channel. This could be 

participates in use and management of VDE-protected docu- used to support the Device Labels requirement of the 

ments may be enhanced with a VDE secure subsystem 50 Trusted Computer System Evaluation Criteria 

supporting an SPE 503 and/or HPE 655. (TCSEC). 

In some organizations, where the threats to secure opera- 2) A writable storage device (e.g., fixed disk, diskette, tape 

tion are relatively low, an HPE 655 may suffice. In other drive* optical disk) connected to or incorporated in an 

organizations (e.g., government defense), it may be neces- electronic appliance 600 may be assigned a set of 

sary to employ an SPE 503 in all situations where VDE- 55 permitted sensitivity attributes. Only documents whose 

protected documents are processed. The choice of enhance- sensitivity attributes belong to this set would be per- 

ment environment and technology may be different in mitted to be stored on the device. This could be used to 

different of the organization. Even if different types of PPE support the TCSEC Device Labels requirement. 

650 are used within an organization to serve different 3) A document may have a list of users associated with it 

requirements, they may be compatible and may operate on 60 representing the users who arc permitted to "handle" 

the same types (or subsets of types) of documents. the document. This list of users may represent, for 

Users may employ application programs that are custom- example, the only users who may view the document, 

ized to operate in cooperation with the VDE for handling of even if other users receive the document container, they 

VDE-protected documents. Examples of this may include could not manipulate the contents. This could be used 

VDE-aware document viewers, VDE aware electronic mail 65 to support the standard ORCON handling caveat, 

systems and similar applications. Those programs may com- 4) A document may have an attribute designating its 

municate with the PPE 650 component of a user's electronic originator and requiring an explicit permission to be 
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granted by an originator before the document's content 
could be viewed. This request for permission may be 
made at the time the document is accessed by a user, or, 
for example, at the time one user distributes the docu- 
ment to another user If permission is not granted, the 5 
document could not be manipulated or otherwise used. 

5) A document may have an attribute requiring that each 
use of the document be reported to the document's 
originator. This may be used by an originator to gauge 
the distribution of the document. Optionally, the report 10 
may be required to have been made successfully before 
any use of the document is permitted, to ensure that the 
use is known to the controlling party at the time of use. 
Alternatively, for example, the report could be made in 
a deferred ("batch") fashion. 15 

6) A document may have an attribute requiring that each 
use of the document be reported to a central document 
tracking clearinghouse. This could be used by the 
organization to track specific documents, to identify 
documents used by any particular user and/or group of 20 
users to track documents with specific attributes (e.g., 
sensitivity), etc. Optionally, for example, the report 
may be required to have been made successfully before 
any use of the document is permitted. 

7) A VDE protected document may have an attribute 
requiring that each use of the document generate a 
"return receipt," to an originator A person using the 
document may be required to answer specific questions 
in order to generate a return receipt, for example by ^ 
indicating why the document is of interest, or by 
indicating some knowledge of the document's contents 
(after reading it). This may be used as assurance that the 
document had been handled by a person, not by any 
automated software mechanism. 35 

8) A VDE protected document's content may be made 
available to a VDE-unaware application program in 
such a way that it is uniquely identifiable (traceable) to 
a user who caused its release. Thus, if the released form 
of the document is further distributed, its origin could 40 
be determined. This may be done by employing VDE 
"fingerprinting" for content release. Similarly, a printed 
VDE protected document may be marked in a similar, 
VDE fingerprinted unique way such that the person 
who originally printed the document could be 45 
determined, even if copies have since been made. 

9) Usage of VDE protected documents could be permitted 
under control of budgets that limit (based on size, time 
of access, etc.) access or other usage of document 
content. This may help prevent wholesale disclosure by 50 
limiting the number of VDE documents accessible to 
an individual during a fixed time period. For example, 
one such control might permit a user, for some particu- 
lar class of documents, to view at most 100 pages/day, 
but only print 10 pages/day and permit printing only on 55 
weekdays between nine and five. As a further example 
a user might be restricted to only a certain quantity of 
logically related, relatively "contiguous" and/or some 
other pattern (such as limiting the use of a database's 
records based upon the quantity of records that share a 60 
certain identifier in field) of VDE protected document 
usage to identify, for example, the occurrence of one or 
more types of excessive database usage (under normal 
or any reasonable circumstances). As a result, VDE 
content providers can restrict usage of VDE content to 65 
acceptable usage characteristics and thwart and/or 
identify (for example, by generating an exception 
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report for a VDE administrator or organization 
supervisor) user attempts to inappropriately use, for 
example, such an information database resource. 

These control capabilities show some examples of how 
VDE can be used to provide a flexible, interactive environ- 
ment for tracking and managing sensitive documents. Such 
an environment could directly trace the flow of a document 
from person to person, by physical locations, by 
organizations, etc. It would also permit specific questions to 
be answered such as "what persons outside the R&D depart- 
ment have received any R&D-controlled document." 
Because the control information is carried with each copy of 
a VDE protected document, and can ensure that central 
registries are updated and/or that originators are notified of 
document use, tracking can be prompt and accurate. 

This contrasts with traditional means of tracking paper 
documents: typically, a paper-oriented system of manually 
collected and handled receipts is used. Documents may be 
individually copy-numbered and signed for, but once dis- 
tributed are not actively controlled. In a traditional paper- 
oriented system, it is virtually impossible to determine the 
real locations of documents; what control can be asserted is 
possible only if all parties strictly follow the handling rules 
(which are at best inconvenient). 

The situation is no better for processing documents within 
the context of ordinary computer and network systems. 
Although said systems can enforce access control informa- 
tion based on user identity, and can provide auditing mecha- 
nisms for tracking accesses to files, these are low-level 
mechanisms that do not permit tracking or controlling the 
flow of content. In such systems, because document content 
can be freely copied and manipulated, it is not possible to 
determine where document content has gone, or where it 
came from. In addition, because the control mechanisms in 
ordinary computer operating systems operate at a low level 
of abstraction, the entities they control are not necessarily 
the same as those that are manipulated by users. This 
particularly causes audit trails to be cluttered with volumi- 
nous information describing uninteresting activities. 
"Fine-Grain" Control Capabilities 

In addition to controlling and managing entire documents, 
users may employ customized VDE-awarc application soft- 
ware to control and manage individual modifications to 
documents. Examples of these capabilities include the fol- 
lowing: 

1) A VDE content user may be permitted to append further 
information to a VDE document to indicate a proposed 
alternative wording. This proposed alteration would be 
visible to all other users (in addition to the original text) 
of the document but would (for example) be able to be 
incorporated into the actual text only by the document's 
owner. 

2) A group of VDE users could be permitted to modify 
one or more parts of a document in such a way that each 
individual alteration would be unambiguously trace- 
able to the specific user who performed it. The rights to 
modify certain portions of a document, and the exten- 
sion of differing sets of rights to different users, allows 
an organization or secure environment to provide dif- 
fering permissions enabling different rights to users of 
the same content. 

3) A group of users could create a VDE document 
incrementally, by building it from individual contribu- 
tions. These contributions would be bound together 
within a single controlled document, but each would be 
individually identified, for example, through their 
incorporation in VDE content containers as embedded 
container objects. 
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4) VDE control and management capabilities could be A "full service" VDE repository may be very attractive to 
used to track activities related to individual document both providers and users of VDE managed content. Provid- 
arcas, for instance recording how many times each ers of VDE managed content may desire to place their 
section of a document was viewed. content in a location that is well known to users, offers 
Example - VDE Protected Content Repository 5 credit, and/or performs audit services for them. In this case, 
As the "Digital Highway" emerges, there is increased providers may be able to focus on creating content, rather 
discussion concerning the distribution of content across ^ D managing the administrative processes associated with 
networks and, in particular, public networks such as the ma king content available in a "retail" fashion, collecting 
Internet. Content may be made available across public audil information from many VDE users, sending and 
networks in several ways including: 10 receiving bills and payments, etc. VDE users may find the 
"mailing" content to a user in response to a request or convenience of a single location (or an integrated arrange- 
advance purchase (sending a token representing the m ent of repositories) appealing as they are attempting to 
commitment of electronic funds or credit to purchase i ocate content of interest. In addition, a full service VDE 
an item); repository may serve as a single location for the reporting of 
supporting content downloadable from an organization's 15 usage information generated as a consequence of their use of 
own content repository, such a repository comprising, VDE managed content received from a VDE repository 
for example, a store of products (such as software and/or, for example, receiving updated software (e.g. VDE- 
programs) and/or a store of information resources, aware applications, load modules, component assemblies, 
normally organized into one or more databases; and non VDE-aware applications, etc.) VDE repository services 
supporting a public repository into which other parties can 20 may be employed in conjunction with VDE content delivery 
deposit their products for redistribution to customers by broadcast and/or on physical media, such as CD-ROM, to 
(normally by making electronic copies for distribution constitute an integrated array of content resources that may 
to a customer in response to a request). be browsed, searched, and/or filtered, as appropriate, to 
One possible arrangement of VDE nodes involves use of fulfill the content needs of VDE users, 
one or more "repositories.** A repository, for example, may 25 A public repository system may be established and main- 
serve as a location from which VDE participants may tained as a non-profit or for-profit service. An organization 
retrieve VDE content containers. In this case, VDE users offering the service may charge a service fee, for example, 
may make use of a network to gain access to a "server** on a per transaction basis and/or as a percentage of the 
system that allows one or more VDE users to access an payments by, and/or cost of, the content to users. A reposi- 
object repository containing VDE content containers. 30 tory service may supply VDE authoring tools to content 
Some VDE participants may create or provide content creators, publishers, distributors, and/or value adding pro- 
and/or VDE content container objects, and then store content viders such that they may apply rules and controls that define 
and/or content objects at a repository so that other partici- some or all of the guidelines managing use of their content 
pants may access such content from a known and/or effi- and so that they may place such content into VDE content 
ciently organized (for retrieval) location. For example, a 35 container objects. 

VDE repository (portion of a VDE repository, multiple VDE A repository may be maintained at one location or may be 

repositories, and/or providers of content to such distributed across a variety of electronic appliances, such as 

repositories) may advertise the availability of certain types a variety of servers (e.g. video servers, etc.) which may be 

of VDE protected content by sending out email to a list of at different locations but nonetheless constitute a single 

network users. If the network users have secure VDE 40 resource. A VDE repository arrangement may employ VDE 

subsystems in their electronic appliances, they may then secure communications and VDE node secure subsystems 

choose to access such a repository directly, or through one ("protected processing environments"). The content com- 

or more smart agents and, using an application program for prising a given collection or unit of information desired by 

example, browse (and/or electronically search) through the a user may be spread across a variety of physical locations, 

offerings of VDE managed content available at the 45 For example, content representing a company's closing 

repository, download desirable VDE content containers, and stock price and the activity (bids, lows, highs, etc.) for the 

make use of such containers. If the repository is successful stock might be located at a World Wide Web server in New 

in attracting users who have an interest in such content, VDE York, and content representing an analysis of the company 

content providers may determine that such a repository is a (such as a discussions of the company's history, personnel, 

desirable locations) to make their content available for easy 50 products, markets, and/or competitors) might be located on 

access by users. If a repository, such as CompuServe, stores a server in Dallas. The content might be stored using VDE 

content in non-encrypted (plaintext) form, it may encrypt mechanisms to secure and audit use. The content might be 

"outgoing" content on an "as needed** basis through placing maintained in clear form if sufficient other forms of security 

such content in VDE con tent containers with desired control are available at such one or more of sites (e.g. physical 

information, and may employ VDE secure communications 55 security, password, protected operating system, data 

techniques for content communication to VDE participants. encryption, or other techniques adequate for a certain con- 

VDE repositories may also offer other VDE services. For tent type). In the latter instances, content may be at least in 

example, a repository may choose to offer financial services part encrypted and placed in VDE containers as it streams 

in the form of credit from the repository that may be used to out of a repository so as to enable secure communication and 

pay fees associated with use of VDE objects obtained from 60 subsequent VDE usage control and usage consequence 

the repository. Alternatively or in addition, a VDE repository management. 

may perform audit information clearinghouse services on A user might request information related to such a com- 

behalf of VDE creators or other participants (e.g. pany including stock and other information. This request 

distributors, redistributors, client administrators, etc.) for might, for example, be routed first through a directory or a 

usage information reported by VDE users. Such services 65 more sophisticated database arrangement located in Boston, 

may include analyzing such usage information, creating This arrangement might contain pointers to, and retrieve 

reports, collecting payments, etc. content from, both the New York and Dallas repositories. 



5,892, 

309 

This information content may, for example, be routed 
directly to the user in two containers (e.g. such as a VDE 
content container object from Dallas and a VDE content 
container object from New York). These two containers may 
form two VDE objects within a single VDE container 5 
(which may contain two content objects containing the 
respective pieces of content from Dallas and New York) 
when processed by the user's electronic appliance. 
Alternatively, such objects might be integrated together to 
form a single VDE container in Boston so that the informa- 10 
lion can be delivered to the user within a single container to 
simplify registration and control at the user's site. The 
information content from both locations may be stored as 
separate information objects or they may be joined into a 
single, integrated information object (certain fields and/or 15 
categories in an information form or template may be filled 
in by one resource and other fields and/or categories may be 
filled by information provided by a different resource). A 
distributed database may manage such a distributed reposi- 
tory resource environment and use VDE to secure the 20 
storing, communicating, auditing, and/or use of information 
through VDE's electronic enforcement of VDE controls. 
VDE may then be used to provide both consistent content 
containers and content control services. 

An example of one possible repository arrangement 3300 25 
is shown in FIG. 78. In this example, a repository 3302 is 
connected to a network 3304 that allows authors 3306 A, 
3306B, 3306C, and 3306D; a publisher 3308; and one or 
more end users 3310 to communicate with the repository 
3302 and with each other. A second network 3312 allows the 30 
publisher 3308, authors 3306E and 3306F, an editor 3314, 
and a librarian 3316 to communicate with each other and 
with a local repository 3318. The publisher 3308 is also 
directly connected to author 3306E. In this example, the 
authors 3306 and publisher 3308 connect to the repository 35 
3302 in order to place their content into an environment in 
which end users 3310 will be able to gain access to a broad 
selection of content from a common location. 

In this example, the repository has two major functional 
areas: a content system 3302A and a clearinghouse system 40 
3302 B. The content system 3302A is comprised of a user/ 
author registration system 3320, a content catalog 3322, a 
search mechanism 3324, content storage 3326, content ref- 
erences 3328, and a shipping system 3330 comprised of a 
controls packager 3322, a container packager 3334, and a 45 
transaction system 3336. The clearinghouse system 3302B 
is comprised of a user/author registration system 3338; 
template libraries 3340; a control structure library 3342; a 
disbursement system 3344; an authorization system 3346 
comprised of a financial system 3348 and a content system so 
3350; a billing system 3352 comprised of a paper system 
3354, a credit card system 3356, and an electronic funds 
transfer (EFT) system 3358; and an audit system 3360 
comprised of a receipt system 3362, a response system 3364, 
a transaction system 3366, and an analysis system 3368. 55 

In this example, author 3306A creates content in elec- 
tronic form that she intends to make broadly available to 
many end users 3310, and to protect her rights through use 
of VDE. Author 3306A transmits a message to the repository 
3302 indicating her desire to register with the repository to 60 
distribute her content. In response to this message, the 
user/author registration system 3320 of the content system 
3302 A, and the user/author registration system 3338 of the 
clearinghouse system 3302 B transmit requests for registra- 
tion information to author 3306A using the network 3304. 65 
These requests may be made in an on-line interactive mode; 
or they may be transmitted in a batch to author 3306 A who 
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then completes the requested information and transmits it as 
a batch to the repository 3302; or some aspects may be 
handled on-line (such as basic identifying information) and 
other information may be exchanged in a batch mode. 

Registration information related to the content system 
3302A may, for example, include: 

a request that Author 3306A provide information con- 
cerning the types and/or categories of content proposed 
for storage and access using the repository, 

the form of abstract and/or other identifying information 
required by the repository-in addition to providing 
author 3306A with an opportunity to indicate whether 
or not author 3306A generally includes other informa- 
tion with content submissions (such as promotional 
materials, detailed information regarding the format of 
submitted content, any equipment requirements that 
should or must be met for potential users of submitted 
content to successfully exploit its value, etc.), 

requests for information from author 3306A concerning 
where the content is to be located (stored at the 
repository, stored at author 3306A*s location, stored 
elsewhere, or some combination of locations), 

what general search characteristics should be associated 
with content submissions (e.g. whether abstracts should 
be automatically indexed for searches by users of the 
repository, the manner in which content titles, abstracts, 
promotional materials, relevant dates, names of per- 
formers and/or authors, or other information related to 
content submissions may or should be used in lists of 
types of content and/or in response to searches, etc.), 
and/or 

how content that is stored at and/or passed through the 
repository should be shipped (including any container 
criteria, encryption requirements, transaction require- 
ments related to content transmissions, other control 
criteria, etc.) 

The information requested from author 3306 A by the 
user/author registration system of the clearinghouse may, for 
example, consist of: 

VDE templates that author 3306 A may or must make use 
of in order to correctly format control information such 
that, for example, the audit system 3360 of the clear- 
inghouse system 3302B is properly authorized to 
receive and/or process usage information related to 
content submitted by author 3306A, 

VDE control information available from the clearing- 
house 3302B that may or must be used by author 3306A 
(and/or included by reference) in some or all of the 
VDE component assemblies created and/or used by 
author 3306 A associated with submitted content, 

the manner in which disbursement of any funds associated 
with usage of content provided by, passed through, or 
collected by the repository clearinghouse system 
3302B should be made, 

the form and/or criteria of authorizations to use submitted 
content and/or financial transactions associated with 
content, 

the acceptable forms of billing for use of content and/or 
information associated with content (such as analysis 
reports that may be used by others), 

how VDE generated audit information should be 
received, 

how responses to requests from users should be managed, 
how transactions associated with the receipt of audit 
information should be formatted and authorized, 
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bow and what forms of analysis should be performed on - incorporated by author 3306A as an aspect of constructing a 
usage information, and/or container for submitted content (in this sense the container 
under what circumstances (if any) usage information delivered to the repository may be in some respects "incom- 
and/or analysis results derived from VDE controlled ptete" until the repository "completes" the container through 
content usage information should be managed 5 use of indicated templates). Such references may be required 
(including to whom they may or must be delivered, the for ^ b Y thc repository 3302 (for example, to place VDE 
form of delivery, any control information that may be ^formation in place to fulfill an aspect of the 
associated with use of such information, etc.) repository's business or security models such as one or more 
The repository 3302 receives the completed registration ma P lab,es corresponding to elements of content necessary 
information from author 3306A and uses this information to 10 for interacting with other VDE control structures to accom- 
build an account profile for author 3306A. In addition, modate ^ a metering, billing, budgeting, and/or other 
software associated with thc authoring process may be and/or distribution related controls of the repository), 
transmitted to author 3306A. This software may, for For example, if content submitted by author 3306A con- 
example, allow author 3306A to place content into a VDE sists of a Periodical publication, a template delivered to the 
content container with appropriate controls in such a way is author b V me repository 3302 when the author registers at 
that many of the decisions associated with creating such me repository may be used as an aspect of an authoring 
containers are made automatically to reflect the use of the application manipulated by the author in creating a VDE 
repository 3302 as a content system and/or a clearinghouse container for such a periodical. Alternatively or in 
system (for example, the location of content, the party to addition, a template designed for use with periodical pub- 
contact for updates to content and/or controls associated 20 Hcations may be resident at the repository 3302, and such a 
with content, the party or parties to whom audit information template may be used by the repository to define, m whole 
may and/or must be transmitted and the pathways for such or iD P^' contro1 structures associated with such a con- 
communication, the character of audit information that is taincr. For example, a VDE template designed to assist in 
collected during usage, the forms of payment that are formulating control structures for periodical publications 
acceptable for use of content, the frequency of audit trans- 25 "fc* mdicate ( amoQ g other that: 
missions required, the frequency of billing, the form of usage controls should include a meter method that records 
abstract and/or other identifying information associated with 6400 ^cle within a publication that a user opens, 
content, the nature of at least a portion of content usage a certain flat rate fee should apply to opening the peri- 
control information, etc.) odical regardless of the number of articles opened, 

Author 3306A makes use of a VDE authoring application 30 and/or 

to specify the controls and the content that she desires to a record should be maintained of every advertisement that 

place within a VDE content container, and produces such a is viewed by a user. 

container in accordance with any requirements of the reposi- If content is maintained in a known and/or identifiable 
tory 3302. Such a VDE authoring application may be, for format, such a template may be used during initial construc- 
example, an application provided by the repository 3302 35 tion of a container without author 3306A*s intervention to 
which can help ensure adherence to repository content identify any map tables that may be required to support such 
control requirements such as the inclusion of one or more recording and billing actions. If such a VDE template is 
types of component assemblies or other VDE control slruc- unavailable to author 3306 A, she may choose to indicate that 
tures and/or required parameter data, an application received the container submitted should be reconstructed (e.g. 
from another party, and/or an application created by author 40 augmented) by the repository to include the VDE control 
3306A in whole or in part. Author 3306A then uses the information specified in a certain template or class of 
network 3304 to transmit the container and any deviations templates. If the format of the content is known and/or 
from author 3306A*s account profile that may relate to such identifiable by the repository, the repository may be able to 
content to the repository 3302. The repository 3302 receives reconstruct (or "complete") such a container automatically, 
the submitted content, and then — in accordance with any 45 One factor in a potentially ongoing financial relationship 
account profile requirements, deviations and/or desired between the repository and author 3306A may relate to 
options in this example — makes a determination as to usage of submitted content by end users 3310. For example, 
whether the content was produced within the boundaries of author 3306A may negotiate an arrangement with the reposi- 
any content and/or control information requirements of thc tory wherein thc repository is authorized to keep 20% of thc 
repository and therefore should be placed within content 50 total revenues generated from end users 3310 in exchange 
storage or referenced by a location pointer or thc like. In for maintaining thc repository services (e.g. making content 
addition to placing the submitted content into content stor- available to end users 3310, providing electronic credit, 
age or referencing such content's location, the repository performing billing activities, collecting fees, etc.) A financial 
3302 may also make note of characteristics associated with relationship may be recorded in control structures in flexible 
such submitted content in the search mechanism 3324, 55 and configurable ways. For example, the financial relation- 
content references 3328, the shipping system 3330, and/or ship described above could be created in a VDE container 
the relevant systems of the clearinghouse system 3302B and/or installation control structure devised by author 3306A 
related to templates and control structures, authorizations, to reflect author 3306 A 's financial requirements and the 
billing and/or payments, disbursements, and/or audits of need for a 20% split in revenue with the repository wherein 
usage information. 60 all billing activities related to usage of submitted content 
During an authoring process, author 3306A may make use could be processed by the repository, and control structures 
of VDE templates. Such templates may be used as an aspect representing reciprocal methods associated with various 
of a VDE authoring application. For example, such tem- component assemblies required for use of author 3306 A's 
plates may be used in the construction of a container as submitted content could be used to calculate the 20% of 
described above. Alternatively or in addition, such templates 65 revenues. Alternatively, the repository may independently 
may also be used when submitted content is received by the and securely add and/or modify control structures original- 
repository 3302. References to such templates may be ing from author 3306A in order to reflect an increase in 
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price. Under some circumstances, author 3306A may not be Some VDE managed content provided to end users 3310 

directly involved (or have any knowledge of) the actual through the repository may be stored in content storage, 

price that the repository charges for usage activities, and Other information may be stored elsewhere, and be refer- 

may concern herself only with the amount of revenue and enced through the content references. In the case where 

character of usage analysis information that she requires for 5 content references are used, the repository may manage the 

her own purposes, which she specifies in VDE control user interactions in such a manner that ail repository content, 

information which governs the use, and consequences of whether stored in content storage or elsewhere (such as at 

use, of VDE controlled content. another site), is presented for selection by end users 3310 in 

Another aspect of the relationship between authors and a uniform way, such as, for example, a consistent or the same 
the repository may involve the character of transaction 10 user interface. If an end user requests delivery of content that 
recording requirements associated with delivery of VDE is not stored in content storage, the VDE repository may 
controlled content and receipt of VDE controlled content locate the actual storage site for the content using informa- 
usagc audit information. For example, author 3306A may lion stored in content references (e.g. the network address 
require that the repository make a record of each user that where the content may be located, a URL, a filesystem 
receives a copy of content from the repository. Author 15 reference, etc.) After the content is located, the content may 
3306A may further require collection of information regard- be transmitted across the network to the repository or it may 
ing the circumstances of delivery of content to such users be delivered directly from where it is stored to the requesting 
(e.g. time, date, etc.) In addition, the repository may elect to end user. In some circumstances (e.g. when container modi- 
perform such transactions for use internally (e.g. to deter- fication is required, when encryption must be changed, if 
mine patterns of usage to optimize systems, detect fraud, 20 financial transactions are required prior to release, etc.), 
etc.) further processing may be required by the repository in order 

In addition to recording information regarding delivery of to prepare such VDE managed content and/or VDE content 
such VDE controlled content, author 3306A may have container for transmission to an end user, 
required or requested the repository to perform certain VDE In order to provide a manageable user interface to the 
container related processes. For example, author 3306 A may 25 content available to VDE repository end users 3310 and to 
want differing abstract and/or other descriptive information provide administrative information used in the determina- 
delivered to different classes of users. In addition, author tion of control information packaged in VDE content con- 
3306A may wish to deliver promotional materials in the tainers shipped to end users 3310, the repository in this 
same container as submitted content depending on, for example includes a content catalog 3322. This catalog is 
example, the character of usage exhibited by a particular 30 used to record information related to the VDE content in 
user (e.g. whether the user has ever received content from content storage, and/or content available through the reposi- 
author 3306A, whether the user is a regular subscriber to tory reflected in content references. The content catalog 
author 3306A's materials, and/or other patterns that may be 3322 may consist of tides of content, abstracts, and other 
relevant to author 3306A and/or the end user that are used to identifying information. In addition, the catalog may also 
help determine the mix of promotional materials delivered to 35 indicate the forms of electronic agreement and/or agreement 
a certain VDE content end user.) In another example, author VDE template applications (offering optional, selectable 
3306A may require that VDE fingerprinting be performed on control structures and/or one or more opportunities to pro- 
such content prior to transmission of content to an end user. vide related parameter data) that are available to end users 

In addition to the form and/or character of content shipped 3310 through the repository for given pieces of content in 

to an end user, authors may also require certain encryption 40 deciding, for example, options and/or requirements for: what 

related processes to be performed by the repository as an type(s) of information is recorded during such content's use, 

aspect of delivering content. For example, author 3306A the charge for certain content usage activities, differences in 

may have required that the repository encrypt each copy of charges based on whether or not certain usage information 

shipped content using a different encryption key or keys in is recorded and/or made available to the repository and/or 

order to help maintain greater protection for content (e.g. in 45 content provider, the redistribution rights associated with 

case an encryption key was "cracked" or inadvertently such content, the reporting frequency for audit 

disclosed, the "damage" could be limited to the portion(s) of transmissions, the forms of credit and/or currency that may 

that specific copy of a certain content deliverable). In be used to pay certain fees associated with use of such 

another example, encryption functions may include the need content, discounts related to certain volumes of usage, 

to use entirely different encryption algorithms and/or tech- 50 discounts available due to the presence of rights associated 

niques in order to fulfill circumstantial requirements (e.g. to with other content from the same and/or different content 

comply with export restrictions). In a further example, providers, sales, etc. Furthermore, a VDE repository content 

encryption related processes may include changing the catalog 3322 may indicate some or all of the component 

encryption techniques and/or algorithms based on the level assemblies that are required in order to make use of content 

of trustedness and/or tamper resistance of the VDE site to 55 such that the end user's system and the repository can 

which content is delivered. exchange messages to help ensure that any necessary VDE 

In addition to transaction information gathered when component assemblies or other VDE control information is 

content Ls shipped from a VDE repository to an end user, the identified, and if necessary and authorized, are delivered 

repository may be required to keep transaction information along with such content to the end user (rather than, for 

related to the receipt of usage information, requests, and/or 60 example, being requested later after their absence has been 

responses to and/or from end users 3310. For example, detected during a registration and/or use attempt), 

author 3306A may require the repository to keep a log of In order to make use of the VDE repository in this 

some or all connections made by end users 3310 related to example, an end user must register with the repository. In a 

transmissions and or reception of information related to the manner similar to that indicated above in the case of an 

use of author 3306A's content (e.g. end user reporting of 65 author, a VDE end user transmits a message from her VDE 

audit information, end user requests for additional perm is- installation to the repository across the network indicating 

sions information, etc.) that she wishes to make use of the services provided by the 
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repository (e.g. access content stored at and/or referenced by connecting to obtain content, the usage requirements for that 

the repository, use credit provided by the repository, etc.) In content may be delivered to them. If the user is connecting 

response to this message, the user/author registration sys- to deliver usage information to the repository, information 

terns of the content system 3302A and the clearinghouse related to that transmission may be delivered to them. Some 

system 3302B of the repository transmit requests for infor- 5 of these processes are described in more detail below 

mation from the end user (e.g. in an on-line and/or batch In this example, when an end user requests content from 

interaction). The information requested by the user/author the VDE repository (e.g. by selecting from a menu of 

registration system of the content system 3302A may available options), the content system 3302A locates the 

include type(s) of content that the user wishes to access, the content either in the content references and/or in content 

characteristics of the user's electronic appliance 600, etc. 10 storage. The content system 3302A may then refer to infor- 

The information requested by the user/author registration mation stored in the content catalog 3322, the end user's 

system of the clearinghouse system 3302B may include account profile, and/or the author's account profile to deter- 

whether the user wishes to establish a credit account with the mine the precise nature of container format and/or control 

clearinghouse system 33Q2B, what other forms of credit the information that may be required to create a VDE content 

user may wish to use for billing purposes, what other 15 container to fulfill the end user's request. The shipping 

clearinghouses may be used by the end user in the course of system then accesses the clearinghouse system 3302Bto 

interacting with content obtained from the repository, any gather any necessary additional control structures to include 

general rules that the user has established regarding their with the container, to determine any characteristics of the 

preferences for release and handling of usage analysis author's and/or end user's account profiles that may influ- 

information, etc. Once the end user has completed the 20 ence either the transaction^) associated with delivering the 

registration information and transmitted it to the repository, content to the end user or with whether the transaction may 

the repository may construct an account profile for the user. be processed. If the transaction is authorized, and all ele- 

In this example, such requests and responses are handled by ments necessary for the container are available, the controls 

secure VDE communications between secure VDE sub- packager forms a package of control information appropriate 

systems of both sending and receiving parties. 25 for this request by this end user, and the container packager 

In order to make use of the repository, the end user may takes this package of control information and the content 
operate application software. In this example, the end user and forms an appropriate container (including any permis- 
may either make use of a standard application program (e.g. sions that may be codeliverable with the container, incor- 
a World Wide Web browser such as Mosaic), or they may porating any encryption requirements, etc.) If required by 
make use of application software provided by the repository 30 the repository or the author's account profile, transactions 
after completion of the registration process. If the end user related to delivery of content are recorded by the transaction 
chooses to make use of the application software provided by system of the shipping system. When the container and any 
the repository, they may be able to avoid certain complexi- transactions related to delivery have been completed, the 
ties of interaction that may occur if a standard package is container is transmitted across the network to the end user, 
used. Although standardized packages are often relatively 35 An end user may make use of credit and/or currency 
easy to use, a customized package that incorporates VDE securely stored within the end user's VDE installation 
aware functionality may provide an easier to use interface secure subsystem to pay for charges related to use of VDE 
for a user. In addition, certain characteristics of the reposi- content received from the repository, and/or the user may 
tory may be built in to the interface to simplify use of the maintain a secure credit and/or currency account remotely at 
services (e.g. similar to the application programs provided 40 the repository, including a "virtual" repository where pay- 
by America Online). ment is made for the receipt of such content by an end user. 

The end user may connect to the repository using the This later approach may provide greater assurance for 
network. In this example, after the user connects to the payment to the repository and/or content providers particu- 
repository, an authentication process will occur. This process larly if the end user has only an HPE based secure sub- 
can either be directed by the user (e.g. through use of a login 45 system. If an end user electronic credit and/or currency 
and password protocol) or may be established by the end account is maintained at the repository in this example, 
user's electronic appliance secure subsystems interacting charges are made to said account based on end user receipt 
with a repository electronic appliance in a VDE authentica- of content from the repository. Further charges to such a 
tion. In cither event, the repository and the user must initially remote end user account may be made based on end user 
ensure that they arc connected to the correct other party. In 50 usage of such received content and based upon content 
this example, if secured information will flow between the usage information communicated to the repository clearing- 
parties, a VDE secured authentication must occur, and a house system 3302B, 

secure session must be established. On the other hand, if the In this example, if an end user does not have a relationship 
information to be exchanged has already been secured established with a financial provider (who has authorized the 
and/or is available without authentication (e.g. certain cata- 55 content providers whose content may be obtained through 
log information, containers that have already been encrypted use of the repository to make use of their currency and/or 
and do not require special handling, etc.), the "weaker" form credit to pay for any usage fees associated with such 
of login/password may be used. provider's content) and/or if an end user desires a new 
Once an end user has connected to the VDE repository source of such credit, the end user may request credit from 
and authentication has occurred, the user may begin raanipu- 60 the repository clearinghouse system 330213. If an end user is 
lating and directing their user interface software to browse approved for credit, the repository may extend credit in the 
through a repository content catalog 3322 (e.g. lists of form of credit amounts (e.g. recorded in one or more UDEs) 
publications, software, games, movies, etc.), use the search associated with a budget method managed by the repository, 
mechanism to help locate content of interest, schedule Periodically, usage information associated with such a bud- 
content for delivery, make inquiries of account status, avail- 65 get method is transmitted by the end user to the audit system 
ability of usage analysis information, billing information, of the repository. After such a transmission (but potentially 
registration and account profile information, etc. If a user is before the connection is terminated), an amount owing is 
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recorded for processing by the billing system, and in accor- from end users 3310 by the receipt system 3362 of the 

dance with the repository's business practices, the amount of clearinghouse. As indicated above, this system may process 

credit available for use by the end user may be replenished the audit information and pass some or all of the output of 

in the same or subsequent transmission. In this example, the sucn a process to the billing system and/or transmit such 

clearinghouse of the repository supports a billing system 5 output to appropriate content authors. Such passing of audit 

with a paper system for resolving amounts owed through the information employs secure VDE pathway of reporting 

mail, a credit card system for resolving amounts owed information handling techniques. Audit information may 

through charges to one or more credit cards, and an dec- also ^ to ^ anal fc tem m order to 

tronic funds transfer system for resolving such amounts anaI ^ resu]ts rdated to end user contem for ^ b 

through direct debits to a bank account. The repository may lfl me ^ ^ u mild ^ majket researchers , 

automatically make payments determined by the disburse- ,l ai i. , , , 

4 3 c r / * . /, . , and/or one or more authors. Analysis results may be based 

ment system for monies owed to authors through use of . . J . / 

• ajj*** i a * -i —i- 4U J^T on a single audit transmission, a portion or an audit 

similar means. Additional detail regarding the audit process . r „ \. ^ " r 

is provided below transmission, a collection of audit transmissions from a 

As indicated above, end users 3310 in this example will end ^ ^ multiple end ^ ^ or 

periodically contact the VDE repository to transmit content 15 combination of audit transmissions based on the subject of 

usage information (e.g. related to consumption of budget, analysis (e.g. usage patterns for a given content element or 

recording of other usage activities, etc.), replenish their collection of elements, usage of certain categories of content 

budgets, modify their account profile, access usage analysis payment histories, demographic usage patterns, etc.) The 

information, and perform other administrative and in form a- response system 3364 is used to send information to the end 

tion exchange activities. In some cases, an end user may 20 user to, for example, replenish a budget, deliver usage 

wish to contact the repository to obtain additional control controls, update permissions information, and to transmit 

structures. For example, if an end user has requested and certain other information and/or messages requested and/or 

obtained a VDE content container from the repository, that required by an end user in the course of their interaction with 

container is typically shipped to the end user along with the clearinghouse. During the course of an end user's 

control structures appropriate to the content, the author's 25 connections and transmissions to and from the 

requirements and account profile, the end user's account clearinghouse, certain transactions (e.g. time, date, and/or 

profile, the content catalog 3322, and/or the circumstances purpose of a connection and/or transmission) may be 

of the delivery (e.g. the first delivery from a particular recorded by the transaction system of the audit system to 

author, a subscription, a marketing promotion, presence reflect requirements of the repository and/or authors, 

and/or absence of certain advertising materials, requests 30 Certain audit information may be transmitted to authors, 

formulated on behalf of the user by the user's local VDE For example, author 3306 A may require that certain infor- 

instancc, etc.) Even though, in this example, the repository mation gathered from an end user be transmitted to author 

may have attempted to deliver all relevant control structures, 3306 A with no processing by the audit system. In this case, 

some containers may include controls structures that allow the fact of the transmission may be recorded by the audit 

for options that the end user did not anticipate exercising 35 system, but author 3306A may have elected to perform their 

(and the other criteria did not automatically select for own usage analysis rather than (or in addition to) permitting 

inclusion in the container) that the end user nonetheless the repository to access, otherwise process and/or otherwise 

determines that they would like to exercise. In this case, the use this information. The repository in this example may 

end user may wish to contact the repository and request any provide author 3306 A with some of the usage information 

additional control information (including, for example, con- 40 related to the repository's budget method received from one 

trol structures) that they will need in order to make use of the or more end users 3310 and generated by the payment of 

content under such option. fees associated with such users' usage of content provided 

For example, if an end user has obtained a VDE content by author 3306A. In this case, author 3306A may be able to 
container with an overall control structure that includes an compare certain usage information related to content with 
option that records of the number of times that certain types 45 the usage information related to the repository's budget 
of accesses are made to the container and further bases usage method for the content to analyze patterns of usage (e.g. to 
fees on the number of such accesses, and another option analyze usage in light of fees, detect possible fraud, generate 
within the overall control structure allows the end user to user profile information, etc.) Any usage fees collected by 
base the fees paid for access to a particular container based the clearinghouse associated with author 3306A's content 
on the length of time spent using the content of the container, 50 that arc due to author 3306A will be determined by the 
and the end user did not originally receive controls that disbursement system of the clearinghouse. The disbursc- 
would support this latter form of usage, the repository may ment system may include usage information (in complete or 
deliver such controls at a later time and when requested by summary form) with any payments to author 3306A rcsu li- 
the user. In another example, an author may have made ing from such a determination. Such payments and inter- 
changes to their control structures (e.g. to reflect a sale, a 55 mation reporting may be an entirely automated sequence of 
new discounting model, a modified business strategy, etc.) processes occurring within the VDE pathway from end user 
which a user may or must receive in order to use the content VDE secure subsystems, to the clearinghouse secure 
container with the changed control structures. For example, subsystem, to the author's secure subsystem, 
one or more control structures associated with a certain VDE In this example, end users 3310 may transmit VDE 
content container may require a "refresh" for continued 60 permissions and/or other control information to the reposi- 
authorization to employ such structures, or the control lory 3302 permitting and/or denying access to usage infor- 
structures may expire. This allows (if desired) a VDE mation collected by the audit system for use by the analysis 
content provider to periodically modify and/or add to VDE system. This, in part, may help ensure end user's privacy 
control information at an end user's site (employing the rights as it relates to the usage of such information. Some 
local VDE secure subsystem). 65 containers may require as an aspect of their control 

Audit information (related to usage of content received structures, that an end user make usage information avail- 

from the repository) in this example is securely received able for analysis purposes. Other containers may give an end 
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user the option of either allowing the usage information to lication for delivery to (and/or referencing by) the repository 

be used for analysis, or denying some or all such uses of 3302. For example, the publisher 3308 may decide (and 

such information. Some users may elect to allow analysis of control by use of said temple) that a periodical publication 

certain Information, and deny this permission for other will have a certain format with respect to the structure of its 

information. End users 3310 in this example may, for 5 content and the types of information that may be included 

example, elect to limit the granularity of information that (e.g. text, graphics, multimedia presentations, 

may be used for analysis purposes (e.g. an end user may advertisements, etc.), the relative location and/or order of 

allow analysis of the number of movies viewed in a time presentation of its content, the length of certain segments, 

period but disallow use of specific titles, an end user may etc. Furthermore, the publisher 3308 may, for example, 

allow release of their ZIP code for demographic analysis, but 10 determine (through distribution of appropriate permissions) 

disallow use of their name and address, etc.) Authors and/or that the publication editor is the only party that may grant 

the repository 3302 may, for example, choose to charge end permissions to write into the container, and that the organi- 

uscrs 3310 smaller fees if they agree to release certain usage zation librarian is the only party that may index and/or 

information for analysis purposes. abstract the content. In addition, the publisher 3308 may, for 

In this example, the repository 3302 may receive content is example, allow only certain one or more parties to finalize 

produced by more than one author. For example, author B, a container for delivery to the repository 3302 in usable form 

author C, and author D may each create portions of content (e.g. by maintaining control over the type of permissions, 

that will be delivered to end users 3310 in a single container. including distribution permissions, that may be required by 

For example, author B may produce a reference work. the repository 3302 to perform subsequent distribution 

Author C may produce a commentary on author B's refer- 20 activities related to repository end users 3310). 

ence work, and author D may produce a set of illustrations In this example, author 3306E is connected directly to the 

for author B's reference work and author C's commentary. publisher 3308, such that the publisher 3308 can provide 

Author B may collect together author C's and author D's templates for that author that establish the character of 

content and add further content (e.g. the reference work containers for author 3306E's content. For example, if 

described above) and include such content in a single 25 author 3306E creates books for distribution by the publisher 

container which is then transmitted to the repository 3302. 3308, the publisher 3308 may define the VDE control 

Alternatively, each of the authors may transmit their works structure template which provides control method options 

to the repository 3302 independently, with an indication that for author 3306E to select from and which provides VDE 

a template should be used to combine their respective works control structures for securely distributing author 3306E*s 

prior to shipping a container to an end user. Still 30 works. Author 3306E and the publisher 3308 may employ 

alternatively, a container reflecting the overall content struc- VDE negotiations for the template characteristics, specific 

turc may be transmitted to the repository 3302 and some or control structures, and/or parameter data used by author 

all of the content may be referenced in the content references 3306E. Author 3306E may then use the template(s) to create 

rather than delivered to the repository 3302 for storage in control structures for their content containers. The publisher 

content storage. 35 3308 may then deliver these works to the repository 3302 

When an end user makes use of container content, their under a VDE extended agreement comprising electronic 

content usage information may, for example, be segregated agreements between author 3306E and the publisher 3308 

in accordance with control structures that organize usage and the repository 3302 and the publisher 3308. 

information based at least in part on the author who created In this example, the publisher 3308 may also make author 

that segment. Alternatively, the authors and/or the VDE 40 3306 E's work available on the local repository 3302. The 

repository 3302 may negotiate one or more other techniques editor may authorize (e.g. through distribution of appropri- 

for securely dividing and/or sharing usage information in ate permissions) author F to create certain portions of 

accordance with VDE control information. Furthermore, content for a publication. In this example, the editor may 

control structures associated with a container may imple- review and/or modify author F's work and further include it 

ment models that differentiate any usage fees associated 45 in a container with content provided by author 3306E 

with portions of content based on usage of particular (available on the local repository 3302). The editor may or 

portions, overall usage of the container, particular patterns of may not have permissions from the publisher 3308 to 

usage, or other mechanism negotiated (or otherwise agreed modify author 3306E's content (depending on any 

to) by the authors. Reports of usage information, analysis negotiations) that may have occurred between the publisher 

results, disbursements, and other clearinghouse processes 50 3308 and author 3306E, and the publisher 3308*s decision to 

may also be generated in a manner that reflects agreements extend such rights to the editor if permissions to modify 

reached by repository 3302 participants (authors, end users author 3306E's content are held in redistributable form by 

3310 and/or the repository 3302) with respect to such the publisher 3308). The editor may also include content 

processes. These agreements may be the result of a VDE from other authors by (a) using a process of granting 

control information negotiation amongst these participants. 55 permissions to authors to write directly into the containers 

In this example, one type of author is a publisher 3308. and/or (b) retrieving containers from the local repository 

The publisher 3308 in this example communicates over an 3302 for inclusion. The local repository 3302 may also be 

"internal" network with a VDE based local repository 3302 used for other material used by the publisher 3308 's orga- 

and over the network described above with the public nization (e.g. databases, other reference works, internal 

repository 3302. The publisher 3308 may ere ate or otherwise 60 documents, draft works for review, training videos, etc.), 

provide content and/or VDE control structure templates that such material may, given appropriate permissions, be 

are delivered to the local repository 3302 for use by other employed in VDE container collections of content created 

participants who have access to the "internal" network. by the editor. 

These templates may be used to describe the structure of The librarian in this example has responsibility for build- 
containers, and may further describe whom in the publisher 65 ing and/or editing inverted indexes, keyword lists (e.g. from 
3308 *s organization may take which actions with respect to a restricted vocabulary), abstracts of content, revision 
the content created within the organization related to pub- histories, etc. The publisher 3308 may, for example, grant 
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permissions to ooly the librarian for creating this type of competitive electronic content products which olTer differing 
content. The publisher 3308 may further require that this overall collections of content and may employ differing 
building and/or editing occur prior to release of content to content control information for content that may be common 
the repository 3302. to sucn multiple products. Importantly, VDE securely and 
Example — Evolution and Transformation of VDE Managed 5 flexibly supports editing the content in, extracting content 
Content and Control Information from , embedding content into, and otherwise shaping the 
The VDE content control architecture allows content content composition of, VDE content containers. Such capa- 
control information (such as control information for gov- bilities allow VDE supported product models to evolve by 
erning content usage) to be shaped to conform to VDE progressively reflecting the requirements of "next" partici- 
control information requirements of multiple parties. For- 10 pants in an electronic commercial model. As a result, a given 
mulating such multiple parly content control information P icce of managed content, as it moves through path- 
normally involves securely deriving control information wavs of handling and branching, can participate in many 
from control information securely contributed by parties different content container and content control information 
who play a role in a content handling and control model (e.g. commercial models. 

content creators), providers), user(s), clearinghouse^), 15 VDE content, and the electronic agreements associated 

etc.). Multiple party control information may be necessary in wim said content, can be employed and progressively 

order to combine multiple pieces of independently managed manipulated in commercial ways which reflect traditional 

VDE content into a single VDE container object business practices for non-electronic products (though VDE 

(particularly if such independently managed content pieces supports greater flexibility and efficiency compared with 

have differing, for example conflicting, content control 20 most of such traditional models). Limited only by the VDE 

information). Such secure combination of VDE managed control information employed by content creators, other 

pieces of content will frequently require VDE's ability to providers, and other pathway of handling and control 

securely derive content control information which accom- participants, VDE allows a "natural" and unhindered flow 

modates the control information requirements, including any o£ and creation of, electronic content product models. VDE 

combinatorial rules, of the respective VDE managed pieces 25 provides for this flow of VDE products and services through 

of content and reflects an acceptable agreement between a network of creators, providers, and users who successively 

such plural control information sets. and securely shape and reshape product composition 

The combination of VDE managed content pieces may through content combining, extracting, and editing within a 

result in a VDE managed composite of content. Combining Virtual Distribution Environment. 

VDE managed content must be carried out in accordance 30 VDE provides means to securely combine content pro- 
with relevant content control information associated with vidcd at different times, by differing sources, and/or repre- 
said content pieces and processed through the use of one or senting differing content types. These types, timings, and/or 
more secure VDE sub-system PPEs 650. VDE's ability to different sources of content can be employed to form a 
support the embedding, or otherwise combining, of VDE complex array of content within a VDE content container, 
managed content pieces, so as to create a combination 35 Fo r example, a VDE content container may contain a 
product comprised of various pieces of VDE content, plurality of different content container objects, each con- 
enables VDE content providers to optimize their VDE taining different content whose usage can be controlled, at 
electronic content products. The combining of VDE man- lea st in part, by its own container's set of VDE content 
aged content pieces may result in a VDE content container control information. 

which "holds" consolidated content and/or concomitant, 40 A VDE content container object may, through the use of 

separate, nested VDE content containers. a sccurG VDE sub-system, be "safely" embedded within a 

VDE's support for creation of content containers holding "parent" VDE content container. This embedding process 

distinct pieces of VDE content portions that were previously may involve the creation of an embedded object, or, 

managed separately allows VDE content providers to alternatively, the containing, within a VDE content 

develop products whose content control information reflects 45 container, of a previously independent and now embedded 

value propositions consistent with the objectives of the object by, at minimum, appropriately referencing said object 

providers of content pieces, and further are consistent with as to lts location. 

the objectives of a content aggregator who may be produc- An embedded content object within a parent VDE content 

ing a certain content combination as a product for commcr- container: 

cial distribution. For example, a content product "launched" 50 (1) may have been a previously created VDE content 
by a certain content provider into a commercial channel container which has been embedded into a parent VDE 
(such as a network repository) may be incorporated by content container by securely transforming it from an 
different content providers and/or end-users into VDE con- independent to an embedded object through the secure 
tent containers (so long as such incorporation is allowed by processing of one or more VDE component assemblies 
the launched product's content control information). These 55 within a VDE secure sub-system PPE 650. In this 
different content providers and/or end-users may, for instance, an embedded object may be subject to content 
example, submit differing control information for regulating control information, including one or more permissions 
use of such content. They may also combine in different records associated with the parent container, but may 
combinations a certain portion of launched content with not, for example, have its own content control infor- 
content received from other parties (and/or produced by 60 mation other than content identification information, or 
themselves) to produce different content collections, given the embedded object may be more extensively con- 
appropriate authorizations. trolled by its own content control information (e.g. 

VDE thus enables copies of a given piece of VDE permissions records), 

managed content to be securely combined into differing (2) may include content which was extracted from another 

consolidations of content, each of which reflects a product 65 VDE content container (along with content control 

strategy of a different VDE content aggregator. VDE's information, as may be applicable) for inclusion into a 

content aggregation capability will result in a wider range of parent VDE content container in the form of an embed- 
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ded VDE content container object. In this case, said content of a VDE container, whether the content is in a 
extraction and embedding may use one or more VDE parent or embedded VDE content container. This may 
processes which run securely within a VDE secure include the use of a VDE aware word processor, for 
sub-system PPE 650 and which may securely remove example, to directly edit (add to, delete, or otherwise 
(or copy) the desired content from a source VDE 5 modify) a VDE container's content. The secure VDE pro- 
content container and place such content in a new or cesses underlying VDE container content editing may be 
existing container object, either of which may be or largely or entirely transparent to the editor (user) and may 
become embedded into a parent VDE content con- transparently enable the editor to securely browse through 
tamer. (using a VDE aware application) some or all of the contents 

(3) may include content which was first created and then 1Q of> and modify one or more of th e VDE content 
placed m a VDE content container object Said receiv- coaUdnm embe dded in, a VDE content container hierarchy, 
ing container may already be embedded in a parent ^ embcdding proccsscs for ^ VDE embedded content 
VDE content container and may already contain other 4 . Ti • i i j .c - *u 
content. The container in which such content is placed confers normaUy involves securely ^entifymg the appro- 
may be specified using a VDE aware application which P nate cont ^ nl "Nation «™ embedded content 
interacts with content and a secure VDE subsystem to 15 For ^ample, VDE content control information for a VDE 
securely create such VDE container and place such installation and/or a VDE content container may securely, 
content therein followed by securely embedding such and transparently to an embedder (user), apply the same 
container into the destination, parent container. content control information to edited (such as modified or 
Alternatively, content may be specified without the use additional) container content as is applied to one or more 
of a VDE aware application, and then manipulated 20 portions (including all, for example) of previously "in place" 
using a VDE aware application in order to manage content of said container and/or securely apply control 
movement of the content into a VDE content container. information generated through a VDE control information 
Such an application may be a VDE aware word negotiation between control sets, and/or it may apply control 
processor, desktop and/or multimedia publishing information previously applied to said content. Application 
package, graphics and/or presentation package, etc. It 25 of control information may occur regardless of whether the 
may also be an operating system function (e.g. part of edited content is in a parent or embedded container. This 
a VDE aware operating system or mini-application same capability of securely applying content control infor- 
operating with an O/S such as a Microsoft Windows mation (which may be automatically and/or transparently 
compatible object packaging application) and move- applied), may also be employed with content that is embed- 
ment of content from "outside" VDE to within a VDE 30 ded into a VDE container through extracting and embedding 
object may, for example, be based on a "drag and drop" content, or through the moving, or copying and embedding, 
metaphor that involves "dragging" a file to a VDE of VDE container objects. Application of content control 
container object using a pointing device such as a information normally occurs securely within one or more 
mouse. Alternatively, a user may "cut" a portion of VDE secure sub-system PPEs 650. This process may 
content and "paste" such a portion into a VDE con- 35 employ a VDE template that enables a user, through easy to 
tainer by first placing content into a "clipboard," then use GUI user interface tools, to specify VDE content control 
selecting a target content object and pasting the content information for certain or all embedded content, and which 
into such an object. Such processes may, at the direc- may include menu driven, user selectable and/or definable 
tion of VDE content control information and under the options, such as picking amongst alternative control meth- 
control of a VDE secure subsystem, put the content 40 ods (e.g. between different forms of metering) which may be 
automatically at some position in the target object, such represented by different icons picturing (symbolizing) dif- 
as at the end of the object or in a portion of the object ferent control functions and apply such functions to an 
that corresponds to an identifier carried by or with the increment of VDE secured content, such as an embedded 
content such as a field identifier, or the embedding object listed on an object directory display. 

process might pop-up a user interface that allows a user 45 Extracting content from a VDE content container, or 
to browse a target object's contents and/or table of editing or otherwise creating VDE content with a VDE 
contents and/or other directories, indexes, etc. Such aware application, provides content which may be placed 
processes may further allow a user to make certain within a new VDE content container object for embedding 
decisions concerning VDE content control information into said parent VDE container, or such content may be 
(budgets limiting use, reporting pathway(s), usage reg- 50 directly placed into a previously existing content container, 
istration requirements, etc.) to be applied to such All of these processes may be managed by processing VDE 
embedded content and/or may involve selecting the content control information within one or more VDE instal- 
specific location for embedding the content, all such lation secure sub-systems. 

processes to be performed as transparently as practical VDE content container objects may be embedded in a 

for the application. 55 parent object through control information referenced by a 

(4) may be accessed in conjunction with one or more parent object permissions record that resolves said embed- 
operating system utilities Tor object embedding and ded object's location and/or contents. In this case, little or no 
linking, such as utilities conforming to the Microsoft change to the embedded object's previously existing content 
OLE standard. In this case, a VDE container may be control information may be required. VDE securely man- 
associated with an OLE "link." Accesses (including 60 aged content which is relocated to a certain VDE content 
reading content from, and writing content to) to a VDE container may be relocated through the use of VDE sub- 
protected container may be passed from an OLE aware system secure processes which may, for example, continue 
application to a VDE aware OLE application that to maintain relocated content as encrypted or otherwise 
accesses protected content in conjunction with control protected (e.g. by secure tamper resistant barrier 502) during 
information associated with such content. 65 a relocation/embedding process. 

A VDE aware application may also interact with compo- Embedded content (and/or content objects) may have 
nent assemblies within a PPE to allow direct editing of the been contributed by different parties and may be integrated 
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into a VDE container through a VDE content and content within a parent VDE content container may employ a 

control information integration process securely managed number of levels, that is a VDE content container nested in 

through the use of one or more secure VDE subsystems. This a VDE content container may itself contain one or more 

process may, for example, involve one or more of: nested VDE content containers. 

(1.) securely applying instructions controlling the embed- 5 VDE content containers may have a nested structure 
ding and/or use of said submitted content, wherein said comprising one or more nested containers (objects) that may 
instructions were securely put in place, at least in part, by a themselves store further containers and/or one or more types 
content provider and/or user of said VDE container. For of content, for example, text, images, audio, and/or any other 
example, said user and/or provider may interact with one or type of electronic information (object content may be speci- 
more user interfaces offering a selection of content embed- 10 fied by content control information referencing, for example, 
ding and/or control options (e.g. in the form of a VDE byte offset locations on storage media). Such content may be 
template). Such options may include which, and/or whether, stored, communicated, and/or used in stream (such as 
one or more controls should be applied to one or more dynamically accumulating and/or flowing) and/or static 
portions of said content and/or the entry of content control (fixed, such as predefined, complete file) form. Such content 
parameter data (such a time period before which said content 15 may be derived by extracting a subset of the content of one 
may not be used, cost of use of content, and/or pricing or more VDE content containers to directly produce one or 
discount control parameters such as software program suite more resulting VDE content containers. VDE securely man- 
sale discounting). Once required and/or optional content aged content (e.g. through the use of a VDE aware appli- 
control information is established by a provider and/or user, cation or operating system having extraction capability) may 
it may function as content control information which may 20 be identified for extraction from each of one or more 
be, in part or in full, applied automatically to certain, or all, locations within one or more VDE content containers and 
content which is embedded in a VDE content container. may then be securely embedded into a new or existing VDE 

(2.) secure VDE managed negotiation activities, including content container through processes executing VDE controls 

the use of a user interface interaction between a user at a in a secure subsystem PPE 650. Such extraction and embed- 

receiving VDE installation and VDE content control infor- 25 ding (VDE "exporting") involves securely protecting, 

mation associated with the content being submitted for including securely executing, the VDE exporting processes, 

embedding. For example, such associated control informa- A VDE activity related to VDE exporting and embedding 

tion may propose certain content information and the con- involves performing one or more transformations of VDE 

tent receiver may, for example, accept, select from a content from one secure form to one or more other secure 

plurality, reject, offer alternative control information, and/or 30 forms. Such transformation^) may be performed with or 

apply conditions to the use of certain content control infor- without moving transformed content to a new VDE content 

mation (for example, accept a certain one or more controls container (e.g. by component assemblies operating within a 

if said content is used by a certain one or more users and/or PPE that do not reveal, in unprotected form, the results or 

if the volume of usage of certain content exceeds a certain other output of such transforming processes without further 

level). 35 VDE processes governing use of at least a portion of said 

(3.) a secure, automated, VDE electronic negotiation content). One example of such a transformation process may 
process involving VDE content control information of the involve performing mathematical transformations and pro- 
receiving VDE content container and/or VDE installation ducing results, such as mathematical results, while retaining, 
and content control information associated with the submit- none, some, or all of the content information on which said 
ted content (such as control information in a permissions 40 transformation was performed. Other examples of such 
record of a contributed VDE object, certain component transformations include converting a document format (such 
assemblies, parameter data in one or more UDEs and/or as from a WordPerfect format to a Word for Windows 
MDEs, etc.). format, or an SGML document to a Postscript document), 

Content embedded into a VDE content container may be changing a video format (such as a QuickTime video format 

embedded in the form of: 45 to a MPEG video format), performing an artificial intelli- 

(1.) content that is directly, securely integrated into pre- gence process (such as analyzing text to produce a summary 
viously existing content of a VDE content container (said report), and other processing that derives VDE secured 
container may be a parent or embedded content container) content from other VDE secured content, 
without the formation of a new container object. Content FIG. 79 shows an example of an arrangement of corn- 
control information associated with said content after 50 mcrcial VDE users. The users in this example create, 
embedding must be consistent with any pre-cmbedding distribute, redistribute, and use content in a variety of ways, 
content control information controlling, at least in part, the This example shows how certain aspects of control infor- 
establishment of control information required after embed- mation associated with content may evolve as control infor- 
ding. Content control information for such directly mation passes through a chain of handling and control, 
integrated, embedded content may be integrated into, and/or 55 These VDE users and controls are explained in more detail 
otherwise comprise a portion of, control information (e.g. in below. 

one or more permissions records containing content control Creator A in this example creates a VDE container and 

information) for said VDE container, and/or provides associated content control information that 

(2.) content that is integrated into said container in one or includes references (amongst other things) to several 

more objects which are nested within said VDE content 60 examples of possible "types" of VDE control information. In 

container object. In this instance, control information for order to help illustrate this example, some of the VDE 

said content may be carried by either the content control control information passed to another VDE participant is 

information for the parent VDE content container, or it may, grouped into three categories in the following more detailed 

for example, be in part or in full carried by one or more discussion: distribution control information, redistribution 

permissions records contained within and/or specifically 65 control information, and usage control information. In this 

associated with one or more content containing nested VDE example, a fourth category of embedding control informa- 

objects. Such nesting of VDE content containing objects tion can be considered an element of all three of the 
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preceding categories. Other groupings of control informa- 
tion are possible (VDE does not require organizing control 
information in this way). The content control information 
associated with this example of a container created by 
creator A is indicated on FIG. 80 as C A . FIG. 80 further s 
shows the VDE participants who may receive enabling 
control information related to creator A*s VDE content 
container. Some of the control information in this example 
is explained in more detail below. 

Some of the distribution control information (in this ]0 
example, control information primarily associated with 
creation, modification, and/or use of control information by 
distributors) specified by creator A includes: (a) distributors 
will compensate creator A for each active user of the content 
of the container at the rate of $10 per user per month, (b) 
distributors are budgeted such that they may allow no more 15 
than 100 independent users to gain access to such content 
(i.e. may create no more than 100 permissions records 
reflecting content access rights) without replenishing this 
budget, and (c) no distribution rights may be passed on in 
enabling control information (e.g. permissions records and 20 
associated component assemblies) created for distribution to 
other participants. 

Some of the content redistribution control information (in 
this example, control information produced by a distributor 
within the scope permitted by a more senior participant in a 25 
chain of handling and control and passed to user/providers 
(in this example, user/distributors) and associated with con- 
trols and/or other requirements associated with redistribu- 
tion activities by such user/distributors) specified by creator 
A includes: (a) a requirement that control information 30 
enabling content access may be redistributed by user/ 
distributors no more than 2 levels, and further requires that 
each redistribution decrease this value by one, such that a 
first redistributor is restricted to two levels of redistribution, 
and a second redistributor to whom the first redistributor 35 
delivers permissions will be restricted to one additional level 
of redistribution, and users receiving permissions from the 
second redistributor will be unable to perform further redis- 
tribution (such a restriction may be enforced, for example, 
by including as one aspect of a VDE control method 40 
associated with creating new permissions a requirement to 
invoke one or more methods that: (i) locate the current level 
of redistribution stored, for example, as an integer value in 
a UDE associated with such one or more methods, (ii) 
compare the level of redistribution value to a limiting value, 45 
and (iii) if such level of redistribution value is less than the 
limiting value, increment such level of redistribution value 
by one before delivering such a UDE to a user as an aspect 
of content control information associated with VDE man- 
aged content, or fail the process if such value is equal to such 50 
a limiting value), and (b) no other special restrictions arc 
placed on redistributors. 

Some of the usage control information (in this example, 
control information that a creator requires a distributor to 
provide in control information passed to users and/or user/ 55 
distributors) specified by creator A may include, for 
example: (a) no moves (a form of distribution explained 
elsewhere in this document) of the content are permitted, 
and (b) distributors will be required to preserve (at a 
minimum) sufficient metering information within usage per- 60 
missions in order to calculate the number of users who have 
accessed the container in a month and to prevent further 
usage after a rental has expired (e.g. by using a meter 
method designed to report access usages to creator A 
through a chain of handling and reporting and/or the use of 65 
expiration dates and/or time-aged encryption keys within a 
permissions record or other required control information). 
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Some of the extracting and/or embedding control infor- 
mation specified by creator A in this example may include a 
requirement that no extracting and/or embedding of the 
content is or will be permitted by parties in a chain of 
handling and control associated with this control 
information, except for users who have no redistribution 
rights related to such VDE secured content provided by 
Creator A. Alternatively, or in addition, as regards different 
portions of said content, control information enabling cer- 
tain extraction and/or embedding may be provided along 
with the redistribution rights described in this example for 
use by user/distributors (who may include user content 
aggregators, that is they may provide content created by, 
and/or received from, different sources so as to create their 
own content products). 

Distributor A in this example has selected a basic 
approach that distributor A prefers when offering enabling 
content control information to users and/or user/distributors 
that favors rental of content access rights over other 
approaches. In this example, some of the control information 
provided by creators will permit distributor A to fulfill this 
favored approach directly, and other control structures may 
disallow this favored approach (unless, for example, dis- 
tributor A completes a successful VDE negotiation allowing 
such an approach and supporting appropriate control 
information). Many of the control structures received by 
distributor A, in this example, are derived from (and reflect 
the results of) a VDE negotiation process in which distribu- 
tor A indicates a preference for distribution control infor- 
mation that authorizes the creation of usage control infor- 
mation reflecting rental based usage rights. Such distribution 
control information may allow distributor A to introduce 
and/or modify control structures provided by creators in 
such a way as to create control information for distribution 
to users and/or user/distributors that, in effect, "rent** access 
rights. Furthermore, distributor A in this example services 
requests from user/distributors for redistribution rights, and 
therefore also favors distribution control information nego- 
tiated (or otherwise agreed to) with creators that permits 
distributor A to include such rights as an aspect of control 
information produced by distributor A. 

In this example, distributor A and creator A may use VDE 
to negotiate (for example, VDE negotiate) for a distribution 
relationship. Since in this example creator A has produced a 
VDE content container and associated control information 
that indicates creator A's desire to receive compensation 
based on rental of usage rights, and such control information 
further indicates that creator A has placed acceptable restric- 
tions in redistribution control information that distributor A 
may use to service requests from user/distributors, distribu- 
tor A may accept creator A*s distribution control information 
without any negotiated changes. 

After receiving enabling distribution control information 
from creator A, distributor A may manipulate an application 
program to specify some or all of the particulars of usage 
control information for users and/or user/distributors 
enabled by distributor A (as allowed, or not prevented, by 
senior control information). Distributor A may, for example, 
determine that a price of $15 per month per user would meet 
distributor A's business objectives with respect to payments 
from users for creator A's container. Distributor A must 
specify usage control information that fulfill the require- 
ments of the distribution control information given to dis- 
tributor A by creator A. For example, distributor A may 
include any required expiration dates and/or time-aged 
encryption keys in the specification of control information in 
accordance with creator A's requirements. If distributor A 
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failed to include such information (or to meet- other malic electronic credit and/or currency payments "executed" 

requirements) in their specification of control information, in response to such usage) as a consequence of such usage 

the control mcthod(s) referenced in creator A's permissions (wherein such consequences may also include electronically, 

record and securely invoked within a PPE 650 to actually securely and automatically receiving a bill delivered through 

create this control information would, in this example, fail to 5 «» of VDE, wherein such a bill is derived from said usage), 

execute in the desired way (e.g. based on checks of proposed ( d ) olhcr actions by user A and/or a VDE secure subsystem 

values in certain fields, a requirement that certain methods al user A ' s VDE installation that are a consequence of such 

be included in permissions, etc.) until acceptable informa- "»B* and/or such control information^ 

tion were included in distributor A's control information \ n ad ^ l,on to ™ ntI °\ information D^CJ, user A may 

enforce her own control information on her usage of creator 

w " i * , . , , t A's VDE content container (within the limits of senior 
In this example user A may have established an account mformatioD)! ^ mnUo{ information may 
with distributor A such that user A may receive VDE for ex fc (a) ^ based, 
managed content usage control information from distributor and/or Qther thresholds placed on ^ that if ^ 
A. User A may receive content usage control information thresholds (e.g. quantity limits, for example, self imposed 
from distributor A to access and use creator A's content. 15 on me amoimt of expenditure per activity parameter) 
Since me usage control information has passed through (and are exceeded user A must give explicit approval before 
been added to, and/or modified by) a chain of handling continuing, (b) privacy requirements of user A with respect 
including distributor A, the usage control information to the recording and/or transmission of certain usage related 
requested from distributor A to make use of creator A's details relating to user A's usage of creator A's content, (c) 
content will, in this example, reflect a composite of control 20 backup requirements that user A places on herself in order to 
information from creator A and distributor A. For example, help ensure a preservation of value remaining in creator A's 
creator A may have established a meter method that will content container and/or local store of electronic credit 
generate an audit record if a user accesses creator A's VDE and/or currency that might otherwise be lost due to system 
controlled content container if the user has not previously failure or other causes. The right to perform in some or all 
accessed the container within the same calendar month (e.g. 25 of these examples of user A's control information, in some 
by storing the date of the user's last access in a UDE examples, may be negotiated with distributor A. Other such 
associated with an open container event referenced in a user specified control information may be enforced inde- 
method core of such a meter method and comparing such a pendent of any control information received from any con- 
date upon subsequent access to determine if such access has tent provider and may be set in relationship to a user's, or 
occurred within the same calendar month). Distributor A 30 more generally, a VDE installation's, control information for 
may make use of such a meter method in a control method one or more classes, or for all classes, of content and/or 
(e.g. also created and/or provided by creator A, or created electronic appliance usage. The entire set of VDE control 
and/or provided by distributor A) associated with opening information that may be in place during user A's usage of 
creator A's container that invokes one or more billing and/or creator A's content container is referred to on FIG. 80 as 
budget methods created, modified, referenced in one or more 35 1^(0^(0^)). This set may represent the control information 
permissions records and/or parameterized by distributor A to originated by creator A, as modified by distributor A, as 
reflect a charge for monthly usage as described above. If further modified by user A, all in accordance with control 
distributor A has specified usage and/or redistribution con- information from value chain parties providing more senior 
trol information within the boundaries permitted by creator control information, and therefore constitutes, for this 
A's senior control information, a new set of control infor- 40 example, a "complete" VDE extended agreement between 
mation (shown as D A (C^) in FIG. 80) may be associated user A, distributor A, and creator A regarding creator A's 
with creator A's VDE content container when control infor- VDE content container. User B may, for example, also 
mation associated with that container by distributor A are receive such control information D^C^) from distributor A, 
delivered to users and/or user/distributors (user A, user B, and add her own control information in authorized ways to 
and user/distributor A in this example). 45 form the set U^D^CjJ). 

In this example, user A may receive control information User/distributor A may also receive VDE control infor- 

related to creator A's VDE content container from distribu- mation from distributor A related to creator A's VDE content 

tor A This control information may represent an extended container. User/distributor A may, for example, both use 

agreement between user A and distributor A (e.g. regarding creator A's content as a user and act as a rcdistributor of 

fees associated with use of content, limited redistribution 50 control information. In this example, control information 

rights, etc.) and distributor A and creator A (e.g. regarding D A (C A ) both enables and limits these two activities. To the 

the character, extent, handling, reporting, and/or other extent permitted by D A (C A ), user/distributor A may create 

aspects of the use and/or creation of VDE controlled content their own control information based on D^QJ — UD A (D A 

usage information and/or content control information (C^)) — that controls both user/distributor A's usage (in a 

received, for example, by distributor A from creator A, or 55 manner similar to that described above in connection with 

vice versa, or in other VDE content usage information user A and user B), and control information redistributed by 

handling). Such an extended agreement is enforced by user/distributor A (in a manner similar to that described 

processes operating within a secure subsystem of each above in connection with distributor A). For example, if 

participant's VDE installation. The portion of such an user/distributor A redistributes UD A (D A (C A )) to user/ 

extended agreement representing control information of 60 distributor B, user/distributor B may be required to report 

creator A as modified by distributor A in this example is certain usage information to user/distributor A that was not 

represented by D^QJ, including, for example, (a) control required by either creator Aor distributor A Alternatively or 

structures (e.g. one or more component assemblies, one or in addition, user/distributor B may, for example, agree to pay 

more permissions records, etc.), (b) the recording of usage user/distributor A a fee to use creator A's content based on 

information generated in the course of using creator A's 65 the number of minutes user/distributor B uses creator A's 

content in conformance with requirements stated in such content (rather than the monthly fee charged to user/ 

control information, (c) making payments (including auto- distributor A by distributor A for user/distributor B's usage). 



5,892,900 

331 332 

In this example, user/distributor A may distribute control • enabling control information sets that may be generated for 

information tlD A (D A (C A )) to user/distributor B that permits users and/or user/distributors, (d) must report information 

user/distributor B to further redistribute control information concerning the number of such distributed control informa- 

associated with creator A's content. User/distributor B may tion sets at certain time intervals (e.g. at least once per 

make a new set of control information UD /f (UD A (D A (C A ))). 5 month), (e) may create control information that allows users 

If the control information UD X (D A (C A )) permits user/ and/or user/distributors to perform up to three moves of their 

distributor B to redistribute, the restrictions on redistribution control information, (£) may allow redistribution of control 

from creator A in this example will prohibit the set \JD ff information by user/distributors up to three levels of 

(UD^D^C^))) from including further redistribution rights redistribution, (g) may allow up to one move per user 

(e.g. providing redistribution rights to user B) because the 10 receiving redistributed control information from a user/ 

chain of handling from distributor A to user/distributor A distributor. 

(distribution) and the continuation of that chain from user/ In this example, distributor A may request control infor- 

distributor A to user/distributor B (first level of mation from creator B that enables distributor A to distribute 

redistribution) and the further continuation of that chain to control information to users and/or user/distributors that is 

another user represents two levels of redistribution, and, 15 associated with the VDE container described above in 

therefore, a set UD^UD^D^QJ)) may not, in this connection with creator B. As stated earlier, distributor A has 

example, include further redistribution rights. established a business model that favors "rental" of access 

As indicated in FIG. 79, user B may employ content from rights to users and user/distributors receiving such rights 

both user/distributor B and distributor A (amongst others). In from distributor A. Creator B's distribution control infor- 

this example, as illustrated in FIG. 80, user B may receive 20 mation in this example does not force a model including 

control information associated with creator A's content from "rental" of rights, but rather bases payment amounts on the 

distributor A and/or user/distributor B. In either case, user B quantity of content decrypted by a user or user/distributor. In 

may be able to establish their own control information on this example, distributor A may use VDE to negotiate with 

Pa(Qa) and/or UD^Up^D^Qj)), respectively (if allowed creator B to include a different usage information recording 

by such control information. The resulting set(s) of control 25 model allowed by creator B. This model may be based on 

information, V^D^C^)) and/or U^(UD /? (UD A (D A (C A )))) including one or more meter methods in control structures 

respectively, may represent different control scenarios, each associated with creator B's container that will record the 

of which may have benefits for user B. As described in number of bytes decrypted by end users, but not charge users 

connection with an earlier example, user B may have a fee based on such decryptions; rather distributor A 

received control information from user/distributor B along a 30 proposes, and creator B's control information agrees to 

chain of handling including user/distributor A that bases fees allow, a "rental" model to charge users, and determines the 

on the number of minutes that user B makes use of creator amount of payments to creator B based on information 

A's content (and requiring user/distributor A to pay fees of recorded by the bytes decrypted meter methods and/or 

$15 per month per user to distributor A regardless of the collections of payment from users. 

amount of usage by user B in a calendar month). This may 35 Creator B may, for example, (a) accept such a new control 

be more favorable under some circumstances than the fees model with distributor A acting as the auditor (e.g. trusting 

required by a direct use of control information provided by a control method associated with processing audit informa- 

distribulor A, but may also have the disadvantage of an tion received by distributor A from users of creator B's 

exhausted chain of redistribution and, for example, further content using a VDE secure subsystem at distributor A's 

usage information reporting requirements included in VD B 40 site, and further to securely calculate amounts owed by 

(tJD A (D A (C A ))). If the two sets of control information distributor A to creator B and, for example, making pay- 

Pa(Qa) and UD B (Up A (D A (C A ))) permit (e.g. do not require merits to creator B using a mutually acceptable budget 

exclusivity enforced, for example, by using a registration method managing payments to creator B from credit and/or 

interval in an object registry used by a secure subsystem of currency held by distributor A), (b) accept such a new 

user B's VDE installation to prevent dc registration and 45 control model based on distributor A's acceptance of a third 

reregistration of different sets of control information related party to perform all audit functions associated with this 

to a certain container (or registration of plural copies of the content, (c) may accept such a model if information asso- 

same content having different control information and/or ciated with the one or more meter methods that record the 

being supplied by different content providers) within a number of bytes decrypted by users is securely packaged by 

particular interval of time as an aspect of an extended 50 distributor B's VDE secure subsystem and is securely, 

agreement for a chain of handling and control reflected in employing VDE communications techniques, sent to creator 

D A (C A ) and/or UDj3(UD A (D A (C A ))) ), user B may have both B in addition to distributor A, and/or (d) other mutually 

sets of control information registered and may make use of acceptable conditions. Control information produced by 

the set that they find preferable under a given usage scenario. distributor A based on modifications performed by distribu- 

In this example, creator B creates a VDE content con- 55 tor A as permitted by C B are referred to in this example as 

tainer and associates a set of VDE control information with D A (C B ). 

such container indicated in FIG. 81 as C B . FIG. 81 further User A may receive a set or control information D A (C B ) 

shows the VDE participants who may receive enabling from distributor A. As indicated above in connection with 

control information related to creator B's VDE content content received from creator A via a chain of handling 

container. In this example, control information may indicate 60 including distributor A, user A may apply their own control 

that distributors of creator B's content: (a) must pay creator information to the control information D A (C fl ), to the extent 

B $0.50 per kilobyte of information decrypted by users permitted by D A (C^), to produce a set of control information 

and/or user/distributors authorized by such a distributor, (b) Va(Pa(^))- Th c °f control information D A (C a ) may 

may allow users and/or user/distributors to embed their include one or more meter methods that record the number 

content container in another container while maintaining a 65 of bytes of content from creator B's container decrypted by 

requirement that creator B receive $0.50 per kilobyte of user A (in order to allow correct calculation of amounts 

content decrypted, (c) have no restrictions on the number of owed by distributor A to creator B for user A's usage of 
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creator B's content in accordance with the control infonna- accessed by users and/or user/distributors, which payment 
tion of C B that requires payment of $0.50 per kilobyte of allows a user to access such an article for a period of no more 
decrypted information), and a further meter method associ- than six months (e.g. using a map-type meter method that is 
ated with recording usage such that distributor A may gather aged once per month, time aged decryption keys, expiration 
sufficient information to securely generate billings associ- 5 dates associated with relevant permissions records, etc.), (b) 
ated with userA's usage of creator B's content and based on control information that allows articles from creator C's 
a "rental" model (e.g. distributor A may, for example, have container to be extracted and embedded into another con- 
included a meter method that records each calendar month tainer for a one time charge per extract/embed of $10, (c) 
that user A makes use of creator B's content, and relates to prohibits extracted/embedded articles from being 
further control information that charges user A $10 per 10 reextracted, (d) permits distributors to create enabling con- 
month for each such month during which user A makes use trol information for up to 1000 users or user/distributors per 
of such content.) User/distributor A may receive control month, (e) requires that information regarding the number of 
information C B directly from creator B. In this case, creator users and user/distributors enabled by a distributor be 
B may use VDE to negotiate with user/distributor A and reported to creator C at least once per week, (f) permits 
deliver a set of control information C B that may be the same 15 distributors to enable users or user/distributors to perform up 
or differ from that described above in connection with the to one move of enabling control information, and (g) permits 
distribution relationship established between creator B and up to 2 levels of redistribution by user/distributors, 
distributor A. For example, user/distributor A may receive In this example, distributor B may establish a distribution 
control information C B that includes a requirement that relationship with creator C. Distributor B in this example 
user/distributor A pay creator B for content decrypted by 20 may have established a business model that favors the 
user/distributor A (and any participant receiving distributed distribution of control information to users and user/ 
and/or redistributed control information from user/ distributors that bases payments to distributor B based on the 
distributor A) at the rate of $0.50 per kilobyte. As indicated number of accesses performed by such VDE participants. In 
above, user/distributor A also may receive control informa- this example, distributor B may create a modified set D^(C C ) 
tion associated with creator B's VDE content container from 25 of enabling control information for distribution to users 
distributor A. In this example, user/distributor A may have a and/or user/distributors. This set Djj(C c ) may, for example, 
choice between paying a "rental" fee through a chain of be based on a negotiation using VDE to establish a fee of 
handling passing through distributor A, and a fee based on $0.10 per access per user for users and/or user/distributors 
the quantity of decryption through a chain of handling direct who receive control information from distributor B. For 
to creator B. In this case, user/distributor A may have the 30 example, if one or more map-type meter methods have been 
ability to choose to use either or both of and D A (C a ). As included in C c to ensure that adequate information may be 
indicated earlier in connection with a chain of handling gathered from users and/or user/distributors to ensure cor- 
including creator A and distributor A, user/distributor A may rect payments to creator C by distributor B based on C c , 
apply her own control information to the extent permitted by such methods may be preserved in the set D^(C C ), and one 
C B and/or D A (C B ) to form the sets of control information 35 or more further meter methods (and any other necessary 
VD A (C B ) and UD A (D A (C fl )), respectively. control structures such as billing and/or budget methods) 
As illustrated in FIG. 81, in this example, user B may may be included to record each access such that the set 
receive control information associated with creator B's VDE D^C C ) will also ensure that distributor B will receive 
content container from six different sources: C B directly payments based on each access. 

from creator B, D A (C fl ) from distributor A, UD^UD^D^ 40 The client administrator in this example may receive a set 

(Off))) and/or \JD B (VD A (C B )) from user/distributor B, of content control information D^(C C ) that differs, for 

Dc(C B ) from distributor C, and/or D^D^C^)) from dis- example, from control information received by user B from 

tributor B. This represents six chains of handling through distributor B. For example, the client administrator may use 

which user B may enter into extended agreements with other VDE to negotiate with distributor B to establish a set of 

participants in this example. Two of these chains pass 45 control information for content from all creators for whom 

through user/distributor B. Based on a VDE negotiation distributor B may provide enabling content control infor- 

between user/distributor B and user B, an extended agree- mation to the client administrator. For example, the client 

ment may be reached (if permitted by control information administrator may receive a set of control information 

governing both parties) that reflects the conditions under D^(C C ) that reflects the results of a VDE negotiation 

which user B may use one or both sets of control informa- 50 between the client administrator and distributor B. The client 

tion. In this example, two chains of handling and control administrator may include a set of modifications to D^(C C ) 

may "converge" at user/distributor B, and then pass to user and form a new set CAfD^Cc)) that includes control 

B (and if control information permits, later diverge once information that may only be available to users and user/ 

again based on distribution and/or redistribution by user B). distributors within the same organization as the client 

In this example, creator C produces one or more sets of 55 administrator (e.g. coworkers, employees, consultants, etc.) 

control information C c associated with a VDE content In order to enforce such an arrangement, CA(D B (C C )) may, 

container created by creator C, as shown in FIG. 82. FIG. 82 for example, include control structures that examine name 

further shows the VDE participants who may receive services information associated with a user or user/ 

enabling control information related to creator C's VDE distributor during registration, establish a new budget 

content container. '1 "he content in such a container is, in this 60 method administered by the client administrator and 

example, organized into a set of text articles. In this example required for use of the content, etc. 

control information may include one or more component A distributor may provide redistribution rights to a client 

assemblies that describe the articles within such a container administrator which allows said administrator to redistribute 

(e.g. one or more event methods referencing map tables rights to create permissions records for certain content 

and/or algorithms that describe the extent of each article). 65 (redistribute rights to use said content) only within the 

C c may further include, for example: (a) a requirement that administrator's organization and to no other parties, 

distributors ensure that creator C receive. $1 per article Similarly, such administrator may extend such a "limited" 
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right to redistribute to department and/or other administrator VDE install a I ion to determine if any of such certain other 
within his organization such that they may redistribute such containers are registered, and further determines the char- 
rights to use content based on one or more restricted lists of actcr of rights held by a user purchasing rights to this 
individuals and/or classes and/or other groupings of orga- container), (c) a requirement that distributors report the 
nization personnel as defined by said administrator. This 5 number of users and user/distributors enabled by control 
VDE capability to limit redistribution to certain one or more information produced in accordance with C D after such 
parties and/or classes and/or other groupings of VDE users number exceeds ^ (d) a requirement that distributors 
and/or installations can be applied to content by any VDE ^ the DUmber of m °7 es bv ^ anoVor user/distributors 
content provider, so long as such a control is allowed by 10 no ™ T * * «? one > < e > a «q«™™£ that distributors limit 
. i . i - user/distnbutors to no more than four levels of 
senior control information. 10 ,-..».* j /r\ *u . i- . -u . * . r 
j . w-fc . . . . . . - r redistribution, and (f) that distributors may create enabling 

User D m this example may receive control [information its other distributors to create 

fromcitherthec^ COQtrol ^ distributors, but may not pass this 

User/distributor C may, for example, distribute control infor- capabi i; ty to ^ enabled distributors, and further requires 

mation UD^CAp^Cc))) to user D that includes a depart- y,^ audit information associated with use of control infor- 

mental budget method managed by user/distributor C to 15 ma ti on by such enabled distributors shall pass directly to 

allow user/distributor C to maintain an additional level of creator D without processing by such enabling distributor 

control over the actions of user D. In this case, UD^CA and that creator D shall pay such an enabling distributor 10% 

(Dfl( c c))) mav include multiple levels of organizational of any payments received by creator D from such an enabled 

controls (e.g. controls originating with the client adminis- distributor. 

trator and further controls originating with user/distributor 20 In this example, distributor C may receive VDE content 

Q in addition to controls resulting from a commercial containers from creator B, creator C, and creator D, and 

distribution channel. In addition or alternatively, the client associated sets of control information C B , C c , and C^. 

administrator may refuse to distribute certain classes of Distributor C may use the embedding control information 

control information to user D even if the client administrator and other control information to produce a new container 

has adequate control information (e.g. control information 25 with two or more VDE objects received from creator B, 

distributed to user/distributor C that allows redistribution to creator C, and creator D. In addition or alternatively, dis- 

users such as user D) to help ensure that control information tributor C may create enabling control information for 

flows through the client administrator's organization in distribution to users and/or user/distributors (or in the case 

accordance with policies, procedures, and/or other admin- of for distributors) for such received containers indi- 

istrativc processes. 30 vidually. For example, distributor C may create a container 

In this example, user E may receive control information including content portions (e.g. embedded containers) from 

from the client administrator and/or distributor B. For creator B, creator C, and creator D in which each such 

example, user E may have an account with distributor B portion has control information related to its access and use 

even though some control information may be received from that records, and allows an auditor to gather, sufficient 

the client administrator. In this case, user E may be permitted 35 information for each such creator to securely and reliably 

to request and receive control information from distributor B receive payments from distributor C based on usage activi- 

without restriction, or the client administrator may have, as ties related to users and/or user/distributors enabled by 

a matter of organizational policy, control information in distributor C. Furthermore, distributor C may negotiate 

place associated with user E's electronic appliance that using VDE with some or all of such creators to enable a 

limits the scope of user E's interaction with distributor B. In 40 model in which distributor C provides overall control infor- 

the latter case, the client administrator may, for example, mation for the entire container based on a "uniform" fee (e.g. 

have limited user E to registering control information with calculated per month, per access, from a combined model, 

the secure subsystem of user E's electronic appliance that is etc.) charged to users and/or user/distributors, while pre- 

not available from the client administrator, is from one or serving the models of each such creator with respect to 

more certain classes of distributors and/or creators, and/or 45 payments due to them by distributor C based on C B , C c , 

has a cost for usage, such as a certain price point (e.g. $50 and/or and, for example, resulting from each of their 

per hour of usage). Alternatively or in addition, the client differing models for the collection of content usage infor- 

administrator may, for example, limit user E to receiving mation and any related (e.g. advertising) information, 

control information from distributor B in which user E In this example, distributor B may receive a VDE content 

receives a more favorable price (or other control information 50 container and associated content control information C E 

criteria) than the price (or other criteria) available in control from creator E as shown in FIG. 83. If C E permits, distribu- 

information from the client administrator. tor B may extract a portion of the content in such a container. 

In this example, creator D may create a VDE content Distributor B may then, for example, embed this portion in 

container that is designed primarily for integration with a container received from distributor C that contains an 

other content (e.g. through use of a VDE extracting/ 55 aggregation of VDE objects created by creator B, creator C, 

embedding process), for example, content provided by ere- and creator D. Depending on the particular restrictions 

ator B and creator C. FIG. 83 shows the VDE participants and/or permissions in the sets of control information 

who may receive enabling control information related a received from each creator and distributor C, distributor B 

VDE content container produced by creator D. Control may, for example, be able to embed such an extracted 

information associated with creator D's content (C^ in FIG. 60 portion into the container received from distributor C as an 

83) may include, for example: (a) a requirement that dis- independent VDE object, or directly into content of "in 

tributors make payment of either $1.50 per open per user, or place" objects from creator B, creator C, and/or creator D. 

$25 per user for an unlimited number of opens, (b) a Alternatively, or in addition, distributor B may, if permitted 

discount of 20% for any user that has previously paid for an by C E , choose to distribute such an extracted portion of 

unlimited number of opens for certain other content created 65 content as an independent VDE object, 

by creator D (e.g. implemented by including one or more User B may, in this example, receive a VDE content 

billing methods that analyze a secure database of a user's container from distributor C that is comprised of VDE 
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objects created by creator B, creator C, and creator D. In ao Audio Library 3406, also available on optical discs, 
addition, user B may receive a VDE content container from and containing various pieces of musical performances 
distributor B that contains the same content created by and vocal performances (for example, historical 
creator B, creator C, and creator D in addition to one or more narrations) which can be used alone or to accompany 
extracted/embedded portions of content created by creator 5 ot her educational historical materials. 
E. User B may base decisions concerning which of such Th e information provided in library 3402, repository 
containers they choose to use (including which embedded 34^ and 340$ may ^ provided to different pub- 
containers she may wish to use) and under which fishers 3408(a), 3408(fc), . . . ,3408(n). Publishers 3408 may, 
circumsunces, based on, for example the character of such ^ ^ ^ SQme Qr aU of ^ mformation they dbudn to 
extracted/embedded portions (e.g. multimedia presentations c ^ users 3410 

illustrating po ten tial areas of interest in the remainder of the . ... A . T n _ _ 

content, commentary explaining and/or exposing other . In «ampk, the Video Library 3402 control informa- 

elcments of content, related works, improved appfication allows publishers to extract objects from the Video 

software delivered as an element of content, etc.); the P roduct container and content control information 

quality, utility, and/or price (or other attributes of control enabling use of each extracted object during a calendar year 

information) of such portions; and other considerations 15 tf me ob J e ^ nas * license cost of $50 or less, and is shorter 

which distinguish the containers and/or content control man 45 minutes in duration, and 20,000 copies of each of 

information received, in this example, from distributor B any other extracted objects, and further requires all video 

and distributor C. objects to be VDE fingerprinted upon decryption. The Audio 

User B may receive content control information from Library 3404 has established similar controls that match its 

distributor B for such a VDE content container that permits 20 business model. The Internet Repository 3406 VDE 

user B to add and/or modify content contained therein. User containerizes, including encrypts, selected object content as 

B may, for example, desire an ability to annotate content in it streams out of the Repository in response to an online, user 

such a container using a VDE aware word processor or other request to download an object. The Repository 3406 may 

applications). If permitted by senior control information, fingerprint the identification of the receiving VDE installa- 

some or all of the content may be available to user B for 25 tion into its content prior to encryption and communication 

modification and/or additions. In this case, user B is acting to a publisher, and may further require user identification 

as a VDE creator for added and/or modified content. User B fingerprinting of their content when decrypted by said 

may, for example, provide new control information for such Publisher or other content user. 

content, or may be required (or desire to) make use of The Publishers 3408 in this example have selected, under 

existing control information (or control information 30 terms and conditions VDE negotiated (or otherwise agreed 

included by senior members of a chain of handling for this to) with the providing resources, various content pieces 

purpose) to manage such content (based on control infor- wn i c h they combine together to form their VDE object 

mation related to such a container and/or contained objects). container products for their teacher customers. Publisher 

In this example, VDE 100 has been used to enable an 3408(A) has combined video objects extracted from the 

environment including, for example, content distribution, 35 video Library 3402 (as indicated by circles), text and image 

redistribution, aggregation (extracting and/or embedding), objects extracted from the Internet Repository 3404 

reaggregation, modification, and usage. The environment in (indicated by diamonds), and one musical piece and one 

this example allows competitive models in which both historical narration extracted from the Audio Library 3406 

control information and content may be negotiated for and indicated by rectangles). Publisher 3408(B) has extracted 

have different particulars based on the chain of handling 40 a similar array of objects to be combined into his product, 

through which control information and/or content has been anc j nas further added graphical elements (indicated by a 

passed. Furthermore, the environment in this example per- hexagon) created by Publisher 3408(B) to enhance the 

mits content to be added to, and/or modified by, VDE product. Publisher 3408(C) has also created a product by 

participants receiving control information that enables such combining objects from the Internet Repository 3404 and 

activities. 45 me Audio Library 3406. In this example, all publisher 

Example - Content Distribution Through a Content VDE products are delivered, on their respective optical discs, in 

Chain of Handling the form of VDE content container objects with embedded 

FIG. 84 reflects certain aspects of a relatively simple objects, to a modern high school for installation on the high 

model 3400 of VDE content distribution involving several school's computer network. 

categories of VDE participants. In this instance, and for 50 i n ^ particular example, End-Users 3410 are teachers 

simplicity of reference purposes, various portions of content wno usc their VDE node's secure subsystems to access the 

arc represented as discrete items in the form of VDE content VDE installation on their high school server that supports 

container objects. One or more of such content portions may the publishers' products (in an alternative example, the high 

also be integrated together in a single object and may (as school may maintain only a server based VDE installation), 

may the contents of any VDE content container object if 55 These teachers license the VDE products from one or more 

allowed by content control information) be extracted in () f lne publishers and extract desired objects from the VDE 

whole or part by a user. In this example, publishers of product content containers and either download the 

historical/educational multimedia content have created VDE extracted VDE content in the form of VDE content contain- 

content containers through the use of content objects avail- crs for storage on their classroom computers and/or as 

able from three content resources: ^ appropriate and/or efficient. The teachers may store 

a Video Library 3402 product available to Publishers on extracted content in the form of VDE content containers on 

optical discs and containing video clip VDE objects server mass storage (and/or if desired and available to an 

representing various historical situations, end-user, and further according to acceptable pricing and/or 

an Internet Repository 3404 which stores history infor- other terms and conditions and/or senior content control 

mation text and picture resources in VDE objects which 65 information, they may store extracted information in "clear" 

are available for downloading to Publishers and other unencrypted form on their nodes' and/or server storage 

users, and means). This allows the teachers to play, and/or otherwise 
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use, the selected portions of said publishers' products, and as group, end-users, etc). In addition, administrators in a VDE 

shown in two instances in this example, add further teacher model may also themselves be VDE content users, 

and/or student created content to said objects. End-user Within an organization, VDE installations may be at each 

3410(2), for example, has selected a video piece 1 received end-user 3454 node, only on servers or other multiple user 

from Publisher A, who received said object from the Video 5 computers or other electronic appliances, or there may be a 

Library. End-user 3410(3) has also received a video piece 3 mixed environment. Determination as to the mix of VDE 

from the same Publisher 3408(A) wherein said piece was server and/or node usage may be based on organization 

also available to her from Publisher 3408(B), but perhaps and/or content provider security, performance, cost 

under not as favorable terms and conditions (such as a overhead, or other considerations. 

support consultation telephone line). In addition, end-user 10 In this example, communications between VDE partici- 

3410(3) has received an audio historical narration from P^k in FIG 85 employs VDE secure communication 

Publisher 3408(B) which corresponds to the content of techniques between VDE secure subsystems supporting 

historical reference piece 7. End-user 3410(3) has also and other VDE secure system components at each 

received a corresponding historical reference piece 7 (a Y° E ^tallation within the organization. 

book) from publisher 3408(2) who received said book from 15 E f X ^ e ~ A f 0 ^ r D ^ uUon t Ex ^P^ Cre ^ 

« ^ * n - A ~ A L M . 4 , . - . . 15 of VDE protected content may interact with other VDE 

the Internet Repository 3404. In this instance, perhaps . - * . . J A unr . %Mm 

ti-t tj/tos'lv . r j participants in many different ways. A VDE creator 102 may, 

publisher J^2) charged less for said book because end- fof ^ ^ dislribute ^ and/of ^ 

user 3410(3) has also licensed historical reference piece 7 mation directl tQ distribute content and/or content 

from him, rather than publisher 3408(1), who also carried control inflation to commercial content repositories, dis- 

the same book. End-user 3410(3), as a teacher, has selected ^ tribute content content control information to corpo- 

the items she considers most appropriate for her classes and, rate con^t repositories, and/or distribute content and/or 

through use of VDE, has been able to flexibly extract such content eoxAxoX information to other VDE participants. If a 

items from resources available to her (in this instance, creator 102 does not interact directly with all users of her 

extracting objects from various optical products provided by content, she may transmit distribution permissions to other 

publishers and available on the local high school network ^ VDE paruc ip ant s that permit such participants to further 

server). distribute content and/or content control information. She 

Example— Distribution of Content Control Information may ^ fa^r distribution of VDE content and/or 

Within an Organization content control information by, for example, not restricting 

FIG. 85 shows two VDE content containers, Container redistribution of control information, or allowing a VDE 

300(A) and Container 300(B), that have been distributed to 30 participant to act as a "conduit" for one or more permissions 

a VDE Client Administrator 3450 in a large organization. As records that can be passed along to another party, wherein 

shown in the figure, Container 300(A) and Container 300 said permissions rccor d provides for including the identifi- 

(B), as they arrive at the corporation, carry certain control cation of the first receiving party and/or the second receiving 

information specifying available usage rights for the orga- party. 

nization. As can be further seen in FIG. 85, the client 35 FIG. 86 shows one possible arrangement of VDE partici- 

administrator 3450 has distributed certain subsets of these pants In lhis exairi ple, CT eator 102 may employ one or more 

rights to certain department administrators 3452 of her application software programs and one or more VDE secure 

organization, such as Sales and Marketing Administrator subsystems to place unencrypted content into VDE pro- 

3452(1), Planning Administrator 3452(2), and Research and t ected form ^ into one or more yDE content containers). 

Development Administrator 3452(k). In each instance, the ^ | n addition, creator 102 may produce one or more distribu- 

Clicnt Administrator 3450 has decided which usage options ^ pensions 3502 and/or usage permissions 3500 as an 

and how much budget should be made available to each aspect of control information associated with such VDE 

department. protected content. Such distribution and/or usage permis- 

FIG. 85 is a simplified example and, for example, the sions 3500 , 3502 may be the same (e.g., all distribution 

Client Administrator 3450 could have added further VDE 45 permissions may have substantively all the same 

controls created by herself and/or modified and/or deleted in characteristics), or they may differ based on the category 

place controls (if allowed by senior content control and/or class of participant for whom they are produced, the 

information) and/or (if allowed by control information) she circumstances under which they are requested and/or 

could have further divided the available monetary budget (or transmitted, changing content control models of cither cre- 

other budgets) among specific usage activities. In this 50 ator 102 or a recipient, etc. 

example, departmental administrators have the same rights In this cxa mpl c , creator 102 transmits (e.g., over a 
to determine the rights of departmental end-users as the network, via broadcast, and/or through transfer of physical 
client administrator has in regard to departments. In media ) VD£ protected content to user U2a, user 1126, 
addition, in this example (but not shown in FIG. 85) the anQ y or user jj^ [ n addition, creator 102 transmits, using 
client administrator 3450 and/or content providers) may 55 VDE secure communications techniques, usage permissions 
also determine certain control information which must t o such users. User 112a, user .1126, and user 112c may use 
directly control (including providing rights related to) end- such vr) E prot ected content within the restrictions of con- 
user content usage and/or the consequences of said usage for lrol m f orrna tion specified by usage permissions received 
all or certain classes of end-users. In the example shown in from creator 102. In this case, creator 102 may, for example, 
FIG. 85, there arc only three levels of VDE participants ^ maDage ^ aspects of such users activities related to VDE 
within the organization: protected content transmitted to them by creator 102. 
a Client Administrator 3450, Alternatively, creator 102 may, for example, include refer- 
department administrators 3452, and ences to control information that must be available to users 
end-users 3454. that is not provided by creator 102 (e.g., component asse ru- 
in other examples, VDE will support many levels of VDE 65 blies managed by another party). 

administration (including overlapping groups) within an Commercial content repository 200g, in this example, 

organization (e.g., division, department, project, network, may receive VDE protected (or otherwise securely 
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delivered) content and distribution, permissions and/or other ■ In this example, corporate content repository 702 within 
content usage control information from creator 102. Com- corporation 700 may receive VDE protected content and 
mcrcial content repository 200g may store content securely distribution permissions from creator 102. The distribution 
such that users may obtain such, when any required condi- permissions received by corporate repository 702 may, for 
tions are met, content from the repository 200g. The distri- 5 example, include restrictions that limit repository 702 to 
bution permissions 3502 may, for example, permit commcr- distribution activities within corporation 700. 
cial content repository 200g to create redistribution rcpos itory 702 may, for example, employ an auto- 
permissions and/or usage permissions 3500, 3502 using a mated tem operatmg in conjunction with a VDE secure 
VDE protected subsystem within certain restrictions subsystem to receive aild/or transmit VDE protected 
described I in content control information received from M ^ ^ redistri5ulion and/or ^permissions. In 
creator 102 (e.g., not to exceed a certain number of copies, . . 4 , r , , 
requiring certain payments by commercial content re£>si- ca5 *> " * u ' omated system may for example, rely on 
torV 200g to creator 102, requiring recipients of such per- cni ™ dcfincd ^ corporate pohcics, departmental pohcics, 
missions to meet certain reporting requirements related to and/or user Preferences to determine the character of per- 
content usage information, etc.). Such content control infor- melons and/or content delivered to vanous parties 
mation may be stored at the repository installation and be 15 (corporation groups and/or individuals) within corporation 
applied to unencrypted content as it is transmitted from said 700 - Sucn a system may, for example, automatically produce 
repository in response to a user request, wherein said content redistribution perm issions for a departmental content reposi- 
is placed into a VDE container as a step in a secure process tory 704 in response to corporation 700 receiving distribu- 
of communicating such content to a user. Redistribution tion permissions from creator 102, and/or produce usage 
permissions may, for example, permit a recipient of such 20 permissions for user 112/ and/or user U2& 
permissions to create a certain number of usage permissions The departmental repository 704 may automatically pro- 
within certain restrictions (e.g., only to members of the same duce usage permissions for user 112g, user H2/i, and/or user 
household, business other organization, etc.). Repository U2L Such users may access content from the corporate 
200g may, for example, be required by control information content repository 702, yet receive usage permissions from 
received from creator 102 to gather and report content usage ^ departmental repository 704. In this case, user U2& user 
information from all VDE participants to whom the reposi- y^lh, and/or user 112/ may receive usage permissions from 
tory has distributed permissions. departmental repository 704 that incorporate departmental 

In this example power user U2d may receive VDE restrictions in additioil to restrictions imposed by senior 
protected content and redistribution Permissions from com- (in mis Ie> frora creat0 r 102, as 
mercial content repository 200g using the desktop computer modificd * repository 702, as may be 
3504. Power user 112 may, for example, then use apphca- r J. , . J , _T - r . J _ ' . t * 4 
tion software in conjunction with a VDE secure subsystem further modified by departmental repository 704, that reflect 
of such desktop computer 3504 in order to produce usage a encoded agreement incorporating ^commercial 
permissions for the desktop computer 3504, laptop computer requirements of creator 102 and corporation 700 in addition 
3506 and/or settop appliance 3508 (assuming redistribution to corporate and/or departmental policies and agreements 
permissions received from commercial content repository 35 with corporate personnel of corporation 700). 
200g permit such activities). If permitted by senior control Example— "Virtual Silicon Container" 
information (for example, from creator 102 as may be As discussed above, VDE in one example provides a 
modified by the repository 200g), power user U2d may add "virtual silicon container" ("virtual black box") in that 
her own restrictions to such usage permissions (e.g., restrict- several different instances of SPU 500 may securely com- 
ing certain members of power user 112*f s household using 40 municate together to provide an overall secure hardware 
the settop appliance to certain times of day, amounts of environment that "virtually" exists at multiple locations and 
usage, etc. based on their user identification information). multiple electronic appliances 600. FIG. 87 shows one 
Power user W2d may then transmit such VDE protected model 3600 of a virtual silicon container. This virtual 
content and usage permissions to the laptop computer 3506 container model 3600 includes a content creator 102, a 
and the settop appliance 3508 using VDE secure commu- 45 content distributor 106, one or more content redistributors 
ni cat ions techniques. In this case, power user Wld has 106a, one or more client administrators 700, one or more 
redistributed permissions from the desktop computer 3504 client users 3602, and one or more clearinghouses 116. Each 
to the settop appliance 3508 and the laptop computer 3506, of these various VDE participants has an electronic appli- 
and periodically the settop appliance and the laptop com- ancc 600 including a protected processing environment 655 
putcr may be required to report content usage information to 50 that may comprise, at least in part, a silicon-based scmicon- 
thc desktop computer, which in turn may aggregate, and/or ductor hardware clement secure processing unit 500. The 
otherwise process, and report user usage information to the various SPUs 500 each encapsulate a part of the virtual 
repository 200g. distribution environment, and thus, together form the virtual 

User 112e and/or user 112/ may receive usage permissions silicon container 3600. 

and VDE protected content from commercial content reposi- 55 Example — Testing/Examinations 

tory 200g. These users may be able to use such content in A scheduled SAT examination for high school seniors is 

ways authorized by such usage information. In contrast to prepared by the Educational Testing Service. The examina- 

power user 1124 these users may not have requested and/or tion is placed in a VDE container for scheduled release on 

received redistribution permissions from the repository Nov. 15, 1994 at 1:00 PM Eastern Standard time. r lne SAT 

200g. In this case, these users may still be able to transfer 60 prepares one copy of the container for each school or other 

some or all usage rights to another electronic appliance 600, location which will conduct the examination. The school or 

and/or they may be permitted to move some of their rights other location ("test site") will be provided with a distributed 

to another electronic appliance, if such transferring and/or examination container securely containing the VDE identi- 

moving is permitted by the usage permissions received from fication for the "administration" electronic appliance and/or 

the repository 200g. In this case, such other appliances may 65 test administrator at the test site (such as, a testing 

be able to report usage information directly to the repository organization) and a budget enabling, for example, the cre- 

200g. ation of 200 test VDE content containers. Each container 
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created at the test site may have a permissions record properly audited and authenticated, that is which person 

containing secure identification information for each elec- took which test, at which time, on which electronic 

Ironic appliance 600, on the test site's network, that will be appliance, at which location. Retesting due to lost, stolen, 

used by a test taker, as well as, for example, an identification improperly timed, or other variables can be avoided or 

for the student who will take the test. The student identifi- 5 eliminated. 

cation could, for example, be in the form of a secure PIN VDE assisted testing may, of course, be employed for 

password which is entered by the student prior to taking the many different applications including secure identification 

test (a test monitor or administrator might verify the student of individuals for security/authentication purposes, for 

identification by entering in a PIN password). Of course, employment (e.g. applying for jobs) applications, and for a 

identification might take the firm of automated voice 10 full range of evaluation testing. For example, an airline pilot, 

recognition, handwriting recognition (signature or a truck, train, or bus driver might take a test immediately 

recognition), fingerprint information, eye recognition, or prior to departure or during travel, with the test evaluating 

similar one or more recognition forms which may be used alertness to test for fatigue, drug use, etc. A certain test may 

either to confirm the identity of the test taker (and/or test have a different order and/or combination of test activities 

monitor/administrator) and/or may be stored with the test is each time, or each group of times, the test is taken. The test 

results in a VDE container or the like or in a location pointed or a master test might be stored in a VDE container (the 

to by certain container information. This identification may order of, and which, test questions might be determined by 

be stored in encrypted or unencrypted form. If stored in a process executed securely within an PPE 650). The test 

encrypted or otherwise protected form, certain summary responses may be encrypted as they occur and either locally 

information, such as error correction information, may be 20 stored for aggregated (or other test result) transmission or 

stored with the identification information to authenticate the dynamically transmitted (for example, to a central test 

associated test as corresponding to the identification. administration computer). If the test taker "flunks" the test, 

As the student takes the test using the computer terminal, perhaps he or she is then prevented from operating the 

the answers selected may be immediately securely stored vehicle, either by a local PPE 650 issuing control instruc- 

(but may be changed by the student during the test session). 25 tions to that effect on some portion of the vehicle's elec- 

Upon the completion of the test, the student's answers, along tronic control system or a local PPE failing to decrypt or 

with a reference to the test, are securely stored in a VDE otherwise provide certain key information required for 

reporting object which is passed along to the network to the vehicle operation, 

test administrator and the administration electronic appli- Example — Appliance Rental 

ance 600. All test objects for all students could then be 30 Through use of the present invention, electronic appli- 
placcd in a VDE object 300 for communication to the ances can be "leased 7 * or otherwise provided to customers 
Educational Testing Service, along with whatever other who, rather than purchasing a given appliance for unlimited 
relevant information (which may also be secured by VDE usage, may acquire the appliance (such as a VCR, television, 
100), including summary information giving average and microwave oven, etc.) and be charged according to one or 
mean scores, and other information that might be desirable 35 more aspects of use. For example, the charge for a micro- 
to summarize and/or act as an authentication of the test wave might be for each time it is used to prepare an item 
objects sent. For example, certain information might be sent and/or for the duration of time used. A telephone jack could 
separately from each student summary object containing be attached, either consistently or periodically, to an inex- 
in formation which helps validate the object as an "authen- pensive modem operatively attached or within the micro- 
tic" test object. 40 wave (the modem might alternatively be located at a 1 oca- 
Applying VDE to testing scenarios would largely elimi- tion which services a plurality of items and/or functions — 
nate cheating resulting from access to tests prior to testing such as burglar alarm, light and/or heat control), 
(normally the tests are stolen from a teacher or test Alternatively, such appliances may make use of a network 
administrator). At ETS, individuals who have access to tests formed by the power cables in a building to transmit and 
could be limited to only a portion of the test to eliminate the 45 receive signals. 

risk of the theft of a "whole" test. Employing VDE would At a periodic interval, usage information (in summary 

also ensure against processing errors or other manipulation form and/or detailed) could be automatically sent to a 

of test answers, since absolutely authentic test results can be remote information utility that collects information on appli- 

archived for a reasonable period of time. ance usage (the utility might service a certain brand, a 

Overall, employing VDE 100 for electronic testing will 50 certain type of appliance, and/or a collection of brands 

enable the benefits of electronic testing to be provided and/or types). The usage information would be sent in VDE 

without the substantial risks associated with electronic form (e.g. as a VDE object 300). The information utility 

storing, communicating, and processing of test materials and might then distribute information to financial clearinghouse 

testing results. Electronic testing will provide enormous (s) if it did not itself perform the billing function, or the 

efficiency improvements, significantly lowering the cost of 55 information "belonging" to each appliance manufacturer 

conducting and processing tests by eliminating printing, and/or lessor (retailer) might be sent to them or to their 

shipping, handling, and human processing of tests. At the agents. In this way a new industry would be enabled of 

same time, electronic testing will allow users to receive a leased usage of appliances where the leases might be analo- 

copy (encrypted or unencrypted) of their test results when gous to car leasing. 

they leave the test sessions. l*his will help protect the tested 60 With VDE installed, appliances could also be managed by 

individual against lost of, or improperly processed, test secure identification (PIN, voice or signature recognition, 

results. Electronic testing employing VDE 100 may also etc.). This might be required each time a unit is used, or on 

ensure that timing related variables of testing (for example some periodic basis. Failure to use the secure identification 

precise starting, duration, and stopping times) can be reli- or use it on a timely basis could disable an appliance if a PPE 

ably managed. And, of course, proper use of VDE 100 for 65 650 issued one or more instructions (or failed to decrypt or 

the testing process can prevent improper access to test otherwise provide certain information critical to appliance 

contents prior to testing and ensure that test taking is operation) that prevented use of a portion or all of the 
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appliance's functions. This feature would greatly reduce the 
desirability of stealing an electronic appliance. A further, 
allied use of VDE is the "registration" of a VDE secure 
subsystem in a given appliance with a VDE secure sub- 
system at some control location in a home or business. This 5 
control location might also be responsible for VDE remote 
communications and/or centralized administration 
(including, for example, restricting your children from view- 
ing R rated movies either on television or videocassettes 
through the recognition of data indicating that a given 
movie, song, channel, game, etc. was R rated and allowing 
a parent to restrict viewing or listening). Such a control 
location may, for example, also gather information on con- 
sumption of water, gas, electricity, telephone usage, etc. 
(either through use of PPEs 650 integrated in control means 
for measuring and/or controlling such consumption, or 15 
through one or more signals generated by non-VDE systems 
and delivered to a VDE secure subsystem, for example, for 
processing, usage control (e.g. usage limiting), and/or 
billing), transmit such information to one or more utilities, 
pay for such consumption using VDE secured electronic 20 
currency and/or credit, etc. 

In addition, one or more budgets for usage could be 
managed by VDE which would prevent improper, excessive 
use of a certain, leased appliance, that might, for example 
lead to failure of the appliance, such as making far more 25 
copies using a photocopier than specified by the duty cycle. 
Such improper use could result in a message, for example on 
a display panel or television screen, or in the form of a 
communication from a central clearinghouse, that the user 
should upgrade to a more robust model. jq 

While the invention has been described in connection 
with what is presently considered to be the most practical 
and preferred embodiment, it is to be understood that the 
invention is not to be limited to the disclosed embodiment, 
but on the contrary, is intended to cover various modifica- 35 
lions and equivalent arrangements included within the spirit 
and scope of the appended claims. 

We claim: 

1. A secure processing unit comprising a CPU, micropro- 
cessor or microcontroller and components designed to per- ^ 
form security-related functions, said components including: 
a secure, tamper-resistant barrier operating to render 
unauthorized interference with or access to the contents 
or operations of the secure processing unit more diffi- 
cult; said barrier including: 45 
a secure bus interface unit, comprising: 

a port designed for connection to a bus external to the 

secure processing unit; 
signal-evaluation circuitry which evaluates signals 
received from said external bus to determine whether 50 
said signals were generated by a trusted source; and 
transmission circuitry which transmits signals between 
said secure processing unit and said external bus, 
said transmission circuitry comprising 
gating circuitry operatively connected to said signal- 55 
evaluation circuitry; said gating circuitry includ- 
ing selective release circuitry which selectively 
releases signals from said external bus for trans- 
mission by said transmission circuitry to said 
secure processing unit or blocks said signals; 60 
said selective release circuitry being controlled, 
at least in part, by signals received from said 
signal-evaluation circuitry, 
a clock, including; 

circuitry which stores time information; 65 
circuitry which updates said time information to reflect 
the passage of time; 
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circuitry designed to output said time information for 

use by said secure processing unit; 
user-controllable circuitry operatively connected to 

adjust said time information; 
parameter circuitry operatively controlled to limit the 
magnitude of an adjustment by said user-controllable 
circuitry to said time information; synchronization 
circuitry operatively connected to an external port, 
said synchronization circuitry further comprising: 
a comparator operatively connected to compare said 
time information with an external timing signal; 
said comparator outputting a non-synch signal in the 
event said comparison indicates a difference 
which exceeds a threshold; 
an encryption/decryption engine; 
a random number generator; 
secure memory; and 

means for creation of one or more secure objects, said 
secure objects comprising at least one control informa- 
tion and content governed by said at least one control 
information. 

2. A secure processing unit as in claim 1, said secure 
processing unit further comprising: 

security circuitry operatively connected to receive said 

non-synch signal; 
said security circuitry including circuitry which performs 

at least one of the following functions in the event of 

receipt of said non-synch signal: 
resetting said circuitry which stores time information so 

that said time information is synchronized with said 

external timing signal; et al 
halting processing of said secure processing unit; 
disabling at least some features of said secure processing 

unit; or 

erasing or otherwise destroying at least some information 
stored in said secure processing unit or in an associated 
memory. 

3. A secure processing unit as in claim 2, said synchro- 
nization circuitry further comprising: 

circuitry designed to accept said external timing signal 
only if said signal evaluation circuitry indicates that 
said external timing signal is received from a secure 
source. 

4. A secure processing unit as in claim 1, said secure 
processing unit further comprising: 

an internal battery used to maintain power to said clock in 
the event of an interruption of external power. 

5. A secure processing unit as in claim 1, said clock 
further comprising: 

a power-interruption indicator circuit which changes state 
if power to said clock has been interrupted. 

6. A secure processing unit as in claim 5, said power- 
interruption indicator circuit further comprising: 

capacitor discharge circuitry which temporarily provides 
power to said power- interruption indicator circuit in the 
event of a power interruption for a period sufficient to 
allow said power-interruption indicator circuit to 
change state in response to said power interruption. 

7. A secure processing unit comprising a CPU micropro- 
cessor or microcontroller and components designed to per- 
form security-related functions, said components including: 

a secure, tamper- resistant barrier operating to render 
unauthorized interference with or access to the contents 
or operations of the secure processing unit more diffi- 
cult; 
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a clock; 

an encryption/decryption engine including 

first encryption/decryption circuitry which encrypts 
and decrypts information using a first encryption 
algorithm; 

second encryption/decryption circuitry which encrypts 
and decrypts information using a second encryption 
algorithm different from said first encryption algo- 
rithm; 

said second encryption algorithm imparting a higher 
degree of cryptographic security to encrypted infor- 
mation than said first encryption algorithm; 

a random number generator, 

secure memory; and 

means for creation of one or more secure objects said 
secure objects comprising at least one control informa- 
tion and content governed by said at least one control 
information. 

8. A secure processing unit as in claim 7, said first 
encryption algorithm comprising a symmetric encryption 
algorithm. 

9. A secure processing unit as in claim 8, said second 
encryption algorithm comprising an asymmetric encryption 
algorithm. 

10. A secure processing unit as in claim 9, said asymmet- 
ric encryption algorithm comprising a public key-private 
key algorithm. 

11. A secure processing unit comprising a CPU, micro- 
processor or microcontroller and components designed to 
perform security-related functions, said components includ- 
ing: 

a secure, tamper-resistant barrier operating to render 
unauthorized interference with or access to the contents 
or operations of the secure processing unit more diffi- 
cult; 

a clock; 

an encryption/decryption engine; 
a random number generator; 

secure memory; said secure memory further comprising: 
circuitry protecting the contents of said memory from 

unauthorized access or alteration; and 
random access memory including volatile random 
access memory and non-volatile random access 
memory; 

said non-volatile random access memory storing one 
or more cryptographic keys; budget information 
and; and information loaded into such memory 
during an initialization process involving commu- 
nication with a VDE administrator 
means for creation of one or more secure obiects, said 
secure objects comprising at least one control informa- 
tion and content governed by said at least one control 
information. 

12. A secure processing unit as in claim 11, said non- 
volatile random access memory storing one or more load 
modules. 

13. A secure processing unit as in claim 12, said non- 
volatile random access memory storing an RPC services 
table, said RPC services table comprising information used 
for routing requests for services. 

14. A secure processing unit comprising a CPU, micro- 
processor or microcontroller and components designed to 
perform security-related functions, said components includ- 
ing: 

a secure, tamper-resistant barrier operating to render 
unauthorized interference with or access to the contents 
or operations of the secure processing unit more diffi- 
cult; 
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a clock; 

an encryption/decryption engine; 
a random number generator; 
secure memory including 

circuitry protecting the contents of said memory from 

unauthorized access or alteration, 
read only memory storing an RPC services table, said 
RPC services table comprising information used for 
routing requests for services; 
means for creation of one or more secure objects, said 
secure objects comprising at least one control informa- 
tion and content governed by said at least one control 
information. 

15. A method of operating a secure processing unit 
comprising a real time clock, said method including the 
following steps: 

initializing said real time clock through the following 
steps: 

receiving time synchronization signals from an external 
source, said time synchronization signals being based 
on Greenwich Mean Time; 
determining whether said external source is secure; 
using said time synchronization signals for said initial- 
ization if said external source is determined to be 
secure; 

comparing the time recorded in said real time clock with 
external time synchronization signals on a regular 
basis; 

if said time recorded in said real time clock is determined 
to be out of synchronization with said external time 
synchronization signals, 
determining the extent of the difference between said time 
recorded in said real time clock and said external time 
synchronization signals; and 
setting an indicator if said time difference exceeds a 
specified threshold. 

16. A method as in claim 15, further comprising the step 
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of: 

following the setting of said indicator, performing one of 
the following steps: 

resetting said time recorded in said real time clock so that 
said time recorded in said real time clock is synchro- 
nized with said external timing signal; 

halting processing of said secure processing unit; 

disabling at least some features of said secure processing 
unit; or 

erasing or otherwise destroying at least some information 
stored in said secure processing unit or in an associated 
memory. 

17. A method as in claim 15, further comprising the step 

of: 

following the setting of said indicator, communicating 
with an external VDE site to obtain correct time infor- 
mation. 

18. A method of operating a secure processing unit 
comprising the steps of: 

receiving an encrypted transmission from an electronic 
appliance; 

using an encryption/decryption engine to determine the 
type of encryption used for such transmission; 

determining that said transmission was encrypted using 
public key encryption; 

using public key decryption techniques to decrypt said 
transmission; 
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obtaining a symmetric key from said decrypted transmis- 
sion; 

using said symmetric key to encrypt a transmission to said 
electronic appliance; and 

using said symmetric key to decrypt at least one addi- 
tional transmission from said electronic appliance 

said at least one additional transmission comprising a 
secure object including at least one control information 
and controlled content; and 

gaining access to said controlled content by complying 
with at least a portion of said at least one control 
information. 

19. A secure processing unit comprising a CPU, micro- 
processor or microcontroller and components designed to 
perform security-related functions, said components includ- 
ing: 

a secure, tamper-resistant barrier operating to render 
unauthorized interference with or access to the contents 
or operations of the secure processing unit more diffi- 
cult; 

a clock; 

an encryption/decryption engine; 
a random number generator; 
secure memory; 

means for the creation of one or more secure objects, said 
secure objects comprising control information and at 
least one file governed by said control information; and 

a secure mode interface switch operatively connected to 
place the secure processing unit into one of at least two 
distinct security-related states; 

a first of said security-related states being a higher- 
security state; and 

a second of said security-related states being a lower- 
security state. 

20. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

secure memory access circuitry operatively connected to 
said secure mode interface switch, said secure memory 
access circuitry allowing access to said secure memory 
when said secure mode interface switch places said 
secure processing unit into said first security-related 
state; 

said secure memory operatively connected to said secure 
memory access circuitry. 

21. A secure processing unit as in claim 20, said secure 
processing unit further comprising: 

an instruction fetch mechanism operatively connected to 
fetch instructions for execution by said secure process- 
ing unit; 

secure instruction fetch circuitry operatively connected to 
said instruction fetch mechanism and to said secure 
mode interface switch and causing said instruction 
fetch mechanism to begin fetching instructions at a 
specified address once said secure mode interface 
switch transitions into said first security state. 

22. A secure processing unit as in claim 21, 

said specified address being an address in said secure 
memory. 

23. A secure processing unit as in claim 20, said secure 
processing unit further comprising: 

an instruction fetch mechanism operatively connected to 
fetch instructions for execution by said secure process- 
ing unit; 

said secure mode interface switch being operatively con- 
nected to said instruction fetch mechanism; 
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said secure mode interface switch further comprising: 
circuitry that sets a transition indication when said secure 

processing unit is about to transition into a different 

security state; 

circuitry that, in response to the setting of said transition 
indication, causes said instruction fetch mechanism to 
begin fetching one or more designated instructions at a 
specified address prior to said secure mode interface 
switch transitioning to said different security state; and 

circuitry that delays said transition into said different 
security state until said instruction fetch mechanism has 
completed fetching said one or more designated 
instructions. 

24. A secure processing unit as in claim 23, 

said one or more designated instructions comprising 
instructions which cause the contents of at least some 
temporary storage locations to be deleted. 

25. A secure processing unit as in claim 24, 

said one or more instructions comprising instructions 
which can only be performed in a privileged operating 
mode of said secure processing unit 

26. A secure processing unit as in claim 20, said secure 
processing unit further comprising: 

interrupt detection circuitry operatively connected to 
external pins of the secure processing unit so as to 
detect externally-generated interrupts; 

said secure mode interface switch operatively connected 
to said interrupt detection circuitry; 

said secure mode interface switch including transition 
circuitry causing said secure mode interface switch to 
transition from one security state to a different security 
state based on detection of one or more interrupts. 

27. A secure processing unit as in claim 20, said secure 
processing unit further comprising: 

a non- volatile memory location storing an initialization 
flag; 

an initialization gate with at least two inputs and one 
output 

one of said inputs connected to receive the state of said 
initialization flag; 

another of said inputs connected to receive an external 
initialization signal; 

said initialization gate operating to output an internal 
initialization signal if said external initialization signal 
is asserted and if said initialization flag is asserted; 

said output of said initialization gate being connected to 
initialization circuitry; 

said initialization circuitry operating to place said secure 
processing unit into an initialization state upon asser- 
tion of said internal initialization signal; 

said initialization circuitry further operating to deassert 
said initialization flag prior to completion of initializa- 
tion of said secure processing unit. 

28. A secure processing unit as in claim 27, said secure 
processing unit further comprising: 

an instruction fetch mechanism operatively connected to 
fetch instructions for execution by said secure process- 
ing unit; 

said initialization circuitry operating to cause said instruc- 
tion fetch mechanism to fetch initialization instructions 
which perform initialization-related functions. 

29. A secure processing unit as in claim 28, further 
comprising: 

a memory storing said initialization instructions. 
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30. A secure processing unit as in claim 29, 

said memory storing said initialization instructions con- 
stituting said secure memory. 

31. A secure processing unit as in claim 28, 

said instruction fetch mechanism fetching said initializa- 
tion instructions at least in part from an external bus. 

32. A secure processing unit as in claim 27, said secure 
processing unit further comprising: 

initialization flag resetting circuitry operatively connected 
to reset said initialization flag after said initialization 
flag has been cleared. 

33. A secure processing unit as in claim 27, said secure 
processing unit further comprising: 

one or more memory locations storing one or more keys; 
validation circuitry operatively connected to use said one 

or more keys to validate one or more digital signatures; 
said initialization circuitry operating to cause said secure 

processing unit to fetch initialization information from 

an external bus; 
said validation circuitry operating to validate one or more 

digital signatures associated with said initialization 

information; 

said secure processing unit failing to process said initial- 
ization information unless said one or more digital 
signatures are validated. 

34. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

a bus interface unit operatively connected to internal 
circuitry of said secure processing unit, to said secure 
mode interface switch and to an external bus, said bus 
interface unit operating to pass signals between said 
external bus and said internal circuitry; 

said bus interface unit containing conditional access cir- 
cuitry; 

said conditional access circuitry operating to pass a first 
type of signals between said external bus and said 
internal circuitry when said secure processing unit is in 
said second security-related state; and 

said conditional access circuitry operating to block pas- 
sage of said first type of signals between said external 
bus and said internal circuitry when said secure pro- 
cessing unit is in said first security-related stale. 

35. A secure processing unit as in claim 34, said first type 
of signals further comprising: 

direct memory access signals. 

36. A secure processing unit as in claim 34, said first type 
of signals further comprising: 

cache coherency signals. 

37. A secure processing unit as in claim 34, said first type 
of signals further comprising: 

interrupt signals. 

38. A secure processing unit as in claim 37, said access 
circuitry operating to hold said first type of signals pending 
transition of said secure processing unit into said second 
security-related state and to pass said first type of signals 
once said transition has occurred. 

39. A secure processing unit as in claim 34, said secure 
processing unit further comprising: 

said conditional access circuitry operating to pass a sec- 
ond type of signals between said external bus and said 
internal circuitry when said secure processing unit is in 
said first security-related state; and 

said conditional access circuitry operating to block pas- 
sage of said second type of signals between said 
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external bus and said internal circuitry when said 
secure processing unit is in said second security-related 
state. 

40. A secure processing unit as in claim 34, said secure 
processing unit further comprising: 

control circuitry responsive to execution of one or more 
instructions by said secure processing unit when said 
secure processing unit is in said first security-related 
state; 

said control circuitry operating to override said condi- 
tional access circuitry, thereby allowing passage of said 
first type of signals between said external bus and said 
internal circuitry when said secure processing unit is in 
said first security-related state. 

41. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

an instruction fetch unit operatively connected to fetch 
instructions for execution by said secure processing 
unit; 

said instruction fetch unit comprising security circuitry 
operatively connected to said secure mode interface 
switch; 

said security circuitry further comprising: 

circuitry which senses the state of said secure mode 
interface switch; 

said instruction fetch circuitry operatively connected to 
fetch instructions from said secure memory while said 
secure mode interface switch indicates that said secure 
processing unit is in said first security-related state, and 
to fetch instructions from non-secure memory while 
said secure mode interface switch indicates that said 
secure processing unit is in said second security-related 
state. 

42. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

secure mode interface switch setting circuitry controlled 
by one or more instructions executable by said secure 
processing unit, said instructions including 

one or more instructions setting said secure mode inter- 
face switch into said first security-related state; and 

one or more instructions setting said secure mode inter- 
face switch into said second security-related state. 

43. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

memory interface circuitry operatively connected to 
receive a memory address constituting a memory loca- 
tion access to which is being sought by said secure 
processing unit; 

secure mode interface switch setting circuitry operatively 
connected to said memory interface circuitry, 

said secure mode interface switch setting circuitry setting 
said secure mode interface switch based on said 
memory address. 

44. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

access circuitry operatively connected to said secure 
mode interface switch; 

said access circuitry allowing operation of at least some 
secure processing unit circuitry when said secure mode 
interface switch is in said first security-related state and 
blocking operation of at least some secure processing 
unit circuitry when said secure mode interface switch is 
in said second security-related state. 
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45. A secure processing unit as in claim 44, said secure 
processing unit circuitry further comprising: 

one or more registers. 

46. A secure processing unit as in claim 44, said secure 
processing unit circuitry further comprising: 

said encryption/decryption engine. 

47. A secure processing unit as in claim 44, said secure 
processing unit circuitry further comprising: 

said clock. 

48. A secure processing unit as in claim 44, said secure 
processing unit circuitry further comprising: 

said random number generator. 

49. A secure processing unit as in claim 44, said secure 
processing unit circuitry further comprising: 

said secure memory. 

50. A secure processing unit as in claim 44, said access 
circuitry further comprising: 

operation completion circuitry operatively connected to 
allow completion of an operation begun on said secure 
processing unit circuitry if said secure mode interface 
switch transitioned to said second security-related state 
after commencement of such operation but prior to 
completion of such operation. 

51. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

mode switch circuitry operatively connected to said 
secure mode interface switch; 

said mode switch circuitry including circuitry to detect the 
state of said secure mode interface switch; 

said mode switch circuitry causing said secure processing 
unit to load state information once said secure mode 
interface switch indicates that said secure processing 
unit has transitioned into said first security state, and 
causing said secure processing unit to commence 
execution based on said state information. 

52. A secure processing unit as in claim 51, 

said mode switch circuitry causing at least some of said 
state information to be loaded into registers in said 
secure processing unit. 

53. A secure processing unit as in claim 51, 

said mode switch circuitry causing said secure processing 
unit to delete at least certain information stored in 
temporary storage locations that are outside said secure 
memory, upon detection that said secure mode interface 
switch indicates that said secure processing unit is 
about to transition or has transitioned into said second 
security stale. 

54. A secure processing unit as in claim 19, said secure 
processing unit further comprising: 

timing circuitry operatively connected to determine the 
number of cycles taken by one or more operations 
performed by said secure processing unit; 

said secure mode interface switch being operatively con- 
nected to said timing circuitry; 

said secure mode interface switch including transition 
circuitry causing said secure mode interface switch to 
transition from one security state to a different security 
state based on information received from said timing 
circuitry. 

55. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit 
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mass storage operatively connected to said central pro- 
cessing unit and said main memory; 

said main memory storing tamper resistant software 
designed to be loaded into said main memory and 
executed by said central processing unit said tamper 
resistant software comprising: 

programming which uses at least one confounding algo- 
rithm to create critical values required for correct 
operation of at least certain functions of said host 
processing environment 

at least one of said confounding algorithms constitutes the 
MD5 algorithm; whereby, said critical values are not 
stored in said mass storage and are therefore resistant to 
discovery. 

56. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit 

mass storage operatively connected to said central pro- 
cessing unit and said main memory; 

said main memory storing tamper resistant software 
designed to be loaded into said main memory and 
executed by said central processing unit, said tamper 
resistant software comprising: 

programming which uses a multiplicity of confounding 
algorithms to create critical values required for correct 
operation of at least certain functions of said host 
processing environment each of said multiplicity of 
differing algorithms using at least one different 
variable, but said differing algorithms being otherwise 
identical; 

at least one of said critical values consisting of a multi- 
plicity of fields, 

said prooramming including critical value creation pro- 
gramming which 

generates a different value for each field of said multi- 
plicity of fields, 

said generation using a different one of said multiplicity 
of confounding algorithms to generate said value for 
each field of said multiplicity of fields, and 

combines said fields to create said critical value, 
a clock, and 

programming which uses values from said clock to com- 
pare the duration of execution of one or more of said 
confounding algorithms to an expected value or range; 

said programming setting an indication depending on the 
results of said comparison; and 

programming which checks said indication and under- 
takes one or more actions in the event that said indi- 
cation indicates that said duration of execution did not 
match said expected value or fall within said expected 
range; 

whereby, said critical values are not stored in said mass 
storage and are therefore resistant to discovery. 

57. A virtual distribution environment as in claim 56 in 
which 

said one or more actions include at least temporarily 
halting further processing. 

58. A virtual distribution environment as in claim 56 in 
which 

said one or more actions include at least temporarily 
disabling certain functions. 

59. A virtual distribution environment as in claim 56 in 
which 



5,892, 

355 

said one or more actions include displaying a message to 
the user. 

60. A virtual distribution environment as in claim 56 in 
which 

said one or more actions include initiating communica- 5 
tions with a trusted server. 

61. A virtual distribution environment as in claim 56 in 
which said one or more actions includes encrypting at least 
some information. 

62. A virtual distribution environment as in claim 56 in 10 
which said one or more actions includes deleting at least 
some information. 

63. A virtual distribution environment as in claim 62 in 
which said deleted information comprises at least one or 
more cryptographic keys. 15 

64. A virtual distribution environment comprising 
a host processing environment comprising 

an operating system. 

a central processing unit; 20 
main memory operatively connected to said central pro- 
cessing unit 

mass storage operatively connected to said central pro- 
cessing unit and said main memory; 

said main memory storing tamper resistant software 25 
designed to be loaded into said main memory and 
executed by said central processing unit, said tamper 
resistant software comprising: 

programming which uses at least one confounding 
algorithm to create critical values required for cor- 30 
rect operation of at least certain functions of said 
host processing environment 
one or more storage locations including one or more 
memory locations allocated by an operating system to 
a boot record file but not used by such file, said memory 35 
locations being located after the end of said file but 
before the end of the memory sector allocated by said 
operating system to said file, said one or more storage 
locations storing 
variables used as inputs to said confounding algorithm 
and/or 

one or more cryptographic keys; 

whereby, said critical values arc not stored in said mass 
storage and are therefore resistant to discovery. 45 

65. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central 
processing unit; 50 

mass storage operatively connected to said central 
processing unit and said main memory said mass 
storage comprising 

a secure storage area storing information at least 
some of which is encrypted, said information 55 
including one or more applications programs, each 
of said applications programs comprising one or 
more applications modules, and at least two 
encrypted applications modules, one of said 
encrypted applications modules having been 60 
encrypted using a first encryption key and a sec- 
ond of said encrypted applications modules hav- 
ing been encrypted using a second encryption key 
different from said first encryption key, and a 
non-secure storage area storing information; 65 
one or more storage locations including one or more 

memory locations allocated by an operating system 
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to a boot record file, but not used by such file, said 
memory locations being located after the end of said 
file but before the end of the memory sector allocated 
by said operating system to said file, 
said one or more storage locations storing one or more 

cryptographic keys; 
one or more storage locations storing at least one of 

said encryption keys, 
programming which controls said host processing envi- 
ronment so as to load said applications modules from 
said secure storage area into said main memory, said 
programming further comprising, 
programming which decrypts said applications mod- 
ules during said loading process, and 
programming which removes at least certain of said 
application modules from said main memory as 
soon as execution of each said application module 
has at least temporarily completed, even if the area 
of said main memory occupied by said application 
module is not yet required for other information, 
whereby the duration of residency of at least certain 
applications modules in an unencrypted state in said 
main memory is limited so as to render analysis of said 
applications modules more difficult. 

66. A method for protecting one or more programs from 
analysis or alteration, said method operating on a host 
processing environment comprising a central processing 
unit, a main memory and one or more mass storage devices, 
said method comprising the following steps: 

encrypting one or more modules of said one or more 
programs; 

storing at least one of said one or more encrypted modules 
in at least one of said one or more mass storage devices, 

decrypting at least one of said one or more modules; 

storing said decrypted module in said main memory; 

executing at least one instruction from said decrypted 
module on said CPU; 

determining whether the next instruction or instruction 
sequence to be executed by said CPU is contained 
within said decrypted module, 

deleting said decrypted module from said main memory if 
said next instruction or instruction sequence is not 
contained within said decrypted module, 

said deletion taking place without consideration of 
whether said next instruction or instruction sequence is 
currently resident in said main memory outside of said 
decrypted module; 

whereby, said decrypted module is removed from main 
memory at the earliest reasonable opportunity, thereby 
rendering analysis of said module more difficult. 

67. A method as in claim 66, said encrypting step further 
comprising: 

encrypting a first module using a first encryption key, and 
encrypting a second module using a second encryption 
key. 

68. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 
a communications port, 
a clock, and 
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trusted server time programming comprising program- 
ming which controls said communications port to con- 
tact a trusted server and programming which obtains a 
time value from said trusted server, and 

clock initialization programming which synchronizes said 
clock to said time value obtained from said trusted 
server, 

said clock initialization programming determining 
whether said time value specified by said clock is the 
same or within a specified range as the time value 
obtained from said trusted server, and 

if said determination results in an affirmative conclusion, 
said clock initialization programming setting an indi- 
cation indicating that said clock has been synchronized 
with said time value obtained from said trusted server, 
and 

if said determination results in a negative conclusion, said 
clock initialization programming performing at least 
one of the following actions: 

setting said time value specified by said clock to be the 
same as or within a specified range of the time value 
obtained from said trusted server, or 

storing a time offset value indicating the difference 
between said time value specified by said clock and the 
time value obtained from said trusted server. 

69. A virtual distribution environment as in claim 68, 
further comprising: 

time integrity programming comprising: 

programming which invokes said trusted server time 
programming, and 

time comparison programming which compares the 
time value specified by said clock to said time value 
obtained from said trusted server, 

determines whether said time values have a specified 
relationship and 

sets an indication based on the result of such determi- 
nation. 

70. A virtual distribution environment as in claim 69, said 
specified relationship consisting of said time value of said 
clock being the same as said time value obtained from said 
trusted server. 

71. A virtual distribution environment as in claim 69, said 
specified relationship consisting of said time value of said 
clock being within a specified range of said time value 
obtained from said trusted server. 

72. A virtual distribution environment as in claim 69, said 
specified relationship consisting of said time value of said 
clock being at a specified offset from said time value 
obtained from said trusted server. 

73. A virtual distribution environment as in claim 69, said 
specified relationship consisting of said time value of said 
clock being within a range of a specified offset from said 
time value obtained from said trusted server. 

74. A virtual distribution environment as in claim 69, said 
time integrity programming further comprising: 

programming which undertakes one or more actions if 
said indication indicates that said time value specified 
by said clock does not have the specified relationship to 
said time value obtained from said trusted server. 

75. A virtual distribution environment as in claim 74 in 
which 

said one or more actions includes at least temporarily 
halting further processing. 

76. A virtual distribution environment as in claim 74 in 
which 

said one or more actions includes at least temporarily 
disabling certain functions. 
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77. A virtual distribution environment as in claim 74 in 
which 

said one or more actions includes displaying a message to 
the user. 

5 78. A virtual distribution environment as in claim 74 in 
which 

said one or more actions includes initiating communica- 
tions with a trusted server. 

79. A virtual distribution environment as in claim 74 in 
10 which 

said one or more actions includes encrypting at least some 
information. 

80. A virtual distribution environment as in claim 74 in 
which 

said one or more actions includes deleting at least some 
information. 

81. A virtual distribution environment as in claim 80 in 
which 

said deleted information comprises at least one or more 
cryptographic keys. 

82. A virtual distribution environment as in claim 74, 
further comprising: 

programming which invokes said time integrity program- 
ming based on the occurrence of one or more specified 
events. 

83. A virtual distribution environment as in claim 82, 
further comprising a timer, 

said one or more specified events including the expiration 
of said timer. 

84. A virtual distribution environment as in claim 82, 
said one or more specified events including the execution 

of a program containing a time integrity programming 
invocation command or sequence of commands. 

85. A virtual distribution environment as in claim 82, 
said one or more specified events including completion of 

execution of a sequence of programming. 

86. A virtual distribution environment as in claim 68, 
further comprising: 

one or more secure containers, comprising secure con- 
tents and one or more rules or controls governing the 
use of said secure contents. 

87. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, a clock, and 
a clock initialization flag, said method comprising the fol- 
lowing steps: 

specifying an acceptable time value range, 
using said communications port to contact a trusted 
server, 

obtaining a trusted time value from said trusted server, 
storing information relating to said trusted time value in 

said host processing environment, 
determining whether said time value on said clock is 
within said acceptable time value range of said trusted 
time value, and 
setting an indication if said time value on said clock is not 
within said acceptable time value range of said trusted 
time value; 
reading said indication, 
if said indication has been set, 
at least temporarily halting further processing. 

88. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
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memory, mass storage, a communications port, a clock, and 
a clock initialization flag, said method comprising the fol- 
lowing steps: 
specifying an acceptable time value range, 
using said communications port to contact a trusted 
server, 

obtaining a trusted time value from said trusted server, 
storing information relating to said trusted time value in 

said host processing environment, 
determining whether said time value on said clock is 

within said acceptable time value range of said trusted 

time value, and 
setting an indication if said time value on said clock is not 

within said acceptable time value range of said trusted 

time value; 
reading said indication, 
if said indication has been set, 
at least temporarily disabling certain functions. 

89. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, a clock, and 
a clock initialization flag, said method comprising the fol- 
lowing steps: 

specifying an acceptable time value range, 
using said communications port to contact a trusted 
server, 

obtaining a trusted time value from said trusted server, 
storing information relating to said trusted time value in 

said host processing environment, 
determining whether said time value on said clock is 

within said acceptable time value range of said trusted 

time value, and 
setting an indication if said time value on said clock is not 

within said acceptable time value range of said trusted 

time value; 
reading said indication, 
if said indication has been set, 
displaying a message to the user 

90. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 
a clock, 

a storage location constituting one or more memory 
locations allocated by an operating system to a boot 
record file, but not used by such file, said memory 
locations being located after the end of said file but 
before the end of the memory sector allocated by said 
operating system to said file, 

execution timing integrity circuitry, said execution timing 
integrity circuitry operatively connected to said clock 
and to said storage location and further comprising, 

comparison circuitry comparing the duration of time 
taken for execution of a program routine with a time 
duration stored in said storage location, 

an indicator indicating whether said expected duration of 
time matches the actual duration; 

programming stored in said main memory, said program- 
ming including 
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commands which cause said host pocessing environ- 
ment to execute program sequences and 

commands which record the time taken for such execu- 
tion in said storage location. 

91. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

executing a program module, 

calculating the duration of said execution, using said 

clock, 
storing said duration, 

executing said program module a second time, 
calculating the duration of said second execution, 
comparing the duration of said second execution to said 

stored duration, 
setting an indicator based on the result of said 

comparison, 

if said indicator indicates that said comparison determined 
that said duration of said second execution was differ- 
ent than or outside a specified range of said stored 
duration, 

at least temporarily halting further processing. 

92. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

executing a program module, 

calculating the duration of said execution, using said 

clock, 
storing said duration, 

executing said program module a second time, 
calculating the duration of said second execution, 
comparing the duration of said second execution to said 

stored duration, 
setting an indicator based on the result of said 

comparison, 

if said indicator indicates that said comparison determined 
that said duration of said second execution was differ- 
ent than or outside a specified range of said stored 
duration, 

at least temporarily disabling certain functions. 

93. A method as in claim 92, said method further com- 
prising the following steps: 

following said disabling of certain functions, using said 
communications port to initiate communications with 
an external trusted server, 

obtaining specified information from said external trusted 
server, 

reselling said indicator, and 
re-enabling said certain functions. 

94. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

executing a program module, 

calculating the duration of said execution, using said 

clock, 
storing said duration, 

executing said program module a second time, 
calculating the duration of said second execution, 
comparing the duration of said second execution to said 
stored duration, 
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setting an indicator based on tbe result of said 
comparison , 

if said indicator indicates that said comparison determined 
that said duration of said second execution was differ- 
ent than or outside a specified range of said stored 
duration, 

displaying a message to the user. 

95. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising tbe following steps: 

executing a program module, 

calculating the duration of said execution, using said 

clock, 
storing said duration, 

executing said program module a second time, 
calculating the duration of said second execution, 
comparing the duration of said second execution to said 

stored duration, 
setting an indicator based on the result of said 

comparison, 

if said indicator indicates that said comparison determined 25 
that said duration of said second executiomwas differ- 
ent than or outside a specified range of said stored 
duration, 

initiating communications with a trusted server. 

30 

96. A method as in claim 95, said method further com- 
prising the following steps: 

obtaining specified information from said trusted server, 
and 

resetting said indicator. 35 

97. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

40 

executing a program module at least once, 
calculating the duration of said execution, using said 
clock, 

storing a value reflecting said duration, 
said value constituting cither the duration of a single said 

execution or a combination or averaging of multiple 

said executions; 
executing said program module a second time, 
calculating the duration of said second execution, 
comparing the duration of said second execution to said 

stored value, 

setting an indicator based on the result of said 
comparison, 

if said indicator indicates that said comparison determined 
that said duration of said second execution was differ- 
ent than or outside a specified range of said stored 
value, 

encrypting at least some information. 

98. A method as in claim 97, said method further com- 
prising the following steps: 

following said encryption of at least some information, 
using said communications port to initiate communi- 
cations with an external trusted server, 

obtaining a cryptographic key from said external trusted 
server, 
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using said cryptographic key to decrypt said information, 
and 

resetting said indicator. 

99. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

executing a program module at least once, 
calculating the duration of said execution, using said 
clock, 

storing a value reflecting said duration, 
said value constituting either the duration of a single said 
execution or a combination or averaging of multiple 
said executions; 
executing said program module a second time, 
calculating the duration of said second execution, 
comparing the duration of said second execution to said 
stored value, 

setting an indicator based on the result of said 
comparison, 

if said indicator indicates that said comparison determined 
that said duration of said second execution was differ- 
ent than or outside a specified range of said stored 
value, 

deleting at least some information. 

100. A method as in claim 99, said method further 
comprising the following steps: 

following said deletion, using said communications port 
to initiate communications with an external trusted 
server, 

obtaining a copy of at least some of said deleted infor- 
mation from said external trusted server, 
storing said information, and 
resetting said indicator. 

101. A method as in claim 100 in which 
said deleted information comprises at least one or more 

cryptographic keys. 

102. A virtual distribution environment comprising 
a host processing environment comprising 
a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 
a communications port, 

a storage location storing one or more values indicating 
the number of designated operations which have 
occurred since initialization of said one or more values, 
said storage location operatively connected to said 
communications port, 

said storage location constituting one or more memory 
locations allocated by an operating system to a boot 
record file, but not used by such file, said memory 
locations being located after the end of said file but 
before the end of the memory sector allocated by 
said operating system to said file, 
updating circuitry operatively connected to increment 
said one or more values upon the occurrence of one of 
said designated operations, 
whereby, a remote device can access said one or more 
values through said communications port. 
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103. A virtual distribution environment comprising 
a host processing environment comprising 
a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 

checksum calculation circuitry which calculates one or 
more checksums based on the value of certain contents 
of said main memory and/or said mass storage 

a storage location operatively connected to said checksum 
calculation circuitry and storing one or more check- 
sums calculated by said checksum calculation circuitry, 

integrity verification circuitry operatively connected to 
said storage location, and to said checksum calculation 
circuitry said integrity verification circuitry including 

circuitry which causes said checksum calculation cir- 
cuitry to calculate a new checksum, 

circuitry which compares said new checksum to one or 
more checksums stored in said storage location, 

indication circuitry which stores and/or communicates an 
indication based on the results of said comparison; and 

programming and/or circuitry which undertakes one or 
more actions if the state of said indication circuitry 
indicates that said checksum comparison resulted in a 
determination that said checksums were not the same; 
said one or more actions including at least temporarily 
halting further processing. 30 

104. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 35 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 

checksum calculation circuitry which calculates one or 
more checksums based on the value of certain contents 40 
of said main memory and/or said mass storage 

a storage location operatively connected to said checksum 
calculation circuitry and storing one or more check- 
sums calculated by said checksum calculation circuitry, 

integrity verification circuitry operatively connected to 
said storage location, and to said checksum calculation 
circuitry, said integrity verification circuitry including 

circuitry which causes said checksum calculation cir- 
cuitry to calculate a new checksum, 

circuitry which compares said new checksum to one or 
more checksums stored in said storage location, 

indication circuitry which stores and/or communicates an 
indication based on the results of said comparison, and 

programming and/or circuitry which undertakes one or 
more actions if the state of 

said indication circuitry indicates that said checksum 
comparison resulted in a 

determination that said checksums were not the same; 
said one or more actions including at least temporarily 
disabling certain functions. 

105. A virtual distribution environment comprising 
a host processing environment comprising 
a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 
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mass storage operatively connected to said central pro- 
cessing unit and said main memory, 

checksum calculation circuitry which calculates one or 
more checksums based on the value of certain contents 
of said main memory and/or said mass storage 

a storage location operatively connected to said checksum 
calculation circuitry and storing one or more check- 
sums calculated by said checksum calculation circuitry, 

integrity verification circuitry operatively connected to 
said storage location, and to said checksum calculation 
circuitry, said integrity verification circuitry including 

circuitry which causes said checksum calculation cir- 
cuitry to calculate a new checksum, 

circuitry which compares said new checksum to one or 
more checksums stored in said storage location, 

indication circuitry which stores and/or communicates an 
indication based on the results of said comparison; and 

programming and/or circuitry which undertakes one or 
more actions if the state of said indication circuitry 
indicates that said checksum comparison resulted in a 
determination that said checksums were not the same; 
said one or more actions including displaying a mes- 
sage to the user. 

106. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 

checksum calculation circuitry which calculates one or 
more checksums based on the value of certain contents 
of said main memory and/or said mass storage 

a storage location operatively connected to said checksum 
calculation circuitry and storing one or more check- 
sums calculated by said checksum calculation circuitry, 

integrity verification circuitry operatively connected to 
said storage location, and to said checksum calculation 
circuitry, said integrity verification circuitry including 

circuitry which causes said checksum calculation cir- 
cuitry to calculate a new checksum, 

circuitry which compares said new checksum to one or 
more checksums stored in said storage location, 

indication circuitry which stores and/or communicates an 
indication based on the results of said comparison; and 

programming and/or circuitry which undertakes one or 
more actions if the state of said indication circuitry 
indicates that said checksum comparison resulted in a 
determination that said checksums were not the same; 

said one or more actions including deleting at least some 
information. 

107. A virtual distribution environment as in claim 106 in 
which 

said deleted information comprises at least one or more 
cryptographic keys. 

108. A virtual distribution environment comprising 
a host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory, 

checksum calculation circuitry which calculates one or 
more checksums based on the value of certain contents 
of said main memory and/or said mass storage 
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a storage location operatively connected to said checksum 
calculation circuitry and storing one or more check- 
sums calculated by said checksum calculation circuitry, 
said storage location further comprising one or more 
memory locations allocated by an operating system 
to a boot record file, but not used by such file, said 
memory locations being located after the end of said 
file but before the end of the memory sector allocated 
by said operating system to said file, 
integrity verification circuitry operatively connected to 
said storage location, and to said checksum calculation 
circuitry, said integrity verification circuitry including 
circuitry which causes said checksum calculation cir- 
cuitry to calculate a new checksum, 
circuitry which compares said new checksum to one or 

more checksums stored in said storage location, and 
indication circuitry which stores and/or communicates an 
indication based on the results of said comparison. 

109. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

initializing a storage location to a known value, 
performing a specified operation, 

incrementing the value contained in said storage location 
for each performance of said specified operation, 

using said communications port to communicate the value 
contained in said storage location to an external trusted 
server, 

said external trusted server 

comparing the results of said contents with expected 
results, and 

setting an indication based on said comparison, and 
undertaking at least one action in response to the setting 

of said indication, said at least one action including 
sending a communication to said host processing 

environment, 

said communication causing said host processing envi- 
ronment to at least temporarily halt further processing. 

110. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 

initializing a storage location to a known value, 

performing a specified operation, 

incrementing the value contained in said storage location 

for each performance of said specified operation, 
using said communications port to communicate the value 

contained in said storage location to an external trusted 

server, 

said external trusted server 

comparing the results of said contents with expected 
results, 

setting an indication based on said comparison, and 
undertaking at least one action in response to the setting 

of said indication, said at least one action including 
sending a communication to said host processing 

environment, 

said communication causing said host processing envi- 
ronment to at least temporarily disable certain func- 
tions. 

111. A method of providing security for a host processing 
environment comprising a central processing unit, a main 
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memory, mass storage, a communications port, and a clock, 
said method comprising the following steps: 
initializing a storage location to a known value, 
performing a specified operation, 
incrementing the value contained in said storage location 
in response to performance of said specified operation, 
using said communications port to communicate the value 
contained in said storage location to an external trusted 
server, 

said external trusted server 

comparing the results of said contents with expected 
results, 

setting an indication based on said comparison, and 
undertaking at least one action in response to the setting 

of said indication, said at least one action including 
sending a communication to said host processing 

environment, 

said communication causing said host processing envi- 
ronment to delete at least some information. 

112. A method as in claim 111 in which 

said deleted information comprises at least one or more 
cryptographic keys. 

113. A virtual distribution environment comprising: 
a central processing unit; 

volatile main memory operatively connected to said cen- 
tral processing unit; 
non-volatile storage operatively connected to said central 

processing unit and said volatile main memory; and 
key loading circuitry operatively connected so as to 
transfer one or more cryptographic keys from said 
non-volatile storage to said volatile main memory; 
said key loading circuitry deleting each of said one or 
more cryptographic keys from said non-volatile 
memory once said cryptographic key has been trans- 
ferred to said volatile main memory; 
said key loading circuitry further comprising circuitry 
restoring said one or more cryptographic keys to said 
non-volatile memory upon detection of a shut-down 
event. 

whereby, detection of said one or more cryptographic 
keys from said non-volatile memory may be rendered 
more difficult. 

114. A virtual distribution environment as in claim 113, 
said storage location further comprising: 

a disk sector marked as damaged. 

115. A virtual distribution environment as in claim 113, 
said storage location further comprising: 

a disk sector designated as an alternative disk sector to be 
used to replace disk sectors marked as damaged. 

116. A virtual distribution environment as in claim 113, 
said storage location further comprising: 

a disk sector normally reserved for non-general purpose 
use. 

117. A virtual distribution environment as in claim 116, 
said disk sector further comprising: 

a disk sector reserved for firmware storage. 

118. A virtual distribution environment as in claim 116, 
said disk sector further comprising: 

a disk sector reserved for storage of information generated 
during testing. 

119. A virtual distribution environment as in claim 113, 
said storage location further comprising: 

a storage location on a writeable, non-volatile semicon- 
ductor memory device, which storage location is nor- 
mally allocated for configuration data. 
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120. A virtual distribution environment as in claim 113, a first of said software identifier storage locations con- 
said storage location further comprising: taining an integrity value embedded in said tamper 

a storage location on a writeable, non-volatile semicon- resistant software at least in part for the purpose of 

ductor memory device, which storage location is nor- identifying said tamper resistant software; and 

mally allocated for firmware. 5 a second of said software identifier storage locations 

121. A virtual distribution environment as in claim 113, containing a string of bits of the same length as said 

said storage location further comprising: mte & ntv value ' ^ of b ! ts ^bedded m said 

tamper resistant software at least m part for the purpose 

a storage location on a wnteable, non-volatile semicon- of obscuring ^id integrity value, 

ductor memory device, which storage location is nor- 130 A yi nua i distribution environment as in claim 129, 

mally allocated for BIOS. said string of bits further comprising: 

122. A virtual distribution environment as in claim 113, bi{s chosen a rarjdom or semi-random process, 
said storage location further comprising: m A vi|1ual distribution environment as in claim 129, 

one or more memory locations allocated by an operating said integrity value further comprising: 

system to a file, but not used by such file. J5 a cryptographic key used to encode or decode at least 

123. A virtual distribution environment as in claim 122, some information stored or used by said host process- 
said one or more memory locations further comprising: m g environment. 

memory locations located after the end of said file but 132. A virtual distribution environment as in claim 129, 

before the end of the memory sector allocated by said said virtual distribution environment further comprising: 

operating system to said file. 20 a registry located in a second host processing environment 

124. A virtual distribution environment as in claim 123, different from said first host processing environment, 
said file further comprising a boot record. said registry comprising: 

125. A virtual distribution environment as in claim 113, initialization software containing insertion programming 
said storage location further comprising an unused storage designed to insert said integrity value in said first 

location allocated to a file allocation map. 25 storage location. 

126. A virtual distribution environment as in claim 113, 133. A virtual distribution environment as in claim 132, 
said storage location further comprising an unused storage Mid second host processing environment further compris- 

location allocated to a directory. m S a random number generator generating random or 

127. A method of providing security for a host processing pseudo-random values; and 

environment comprising a central processing unit, a main 30 said insertion programming further comprising program- 
memory, mass storage, a communications port, and a clock, min 8 inserting a random value generated by said ran- 
said method comprising the following steps: dom number generator in said second software identi- 

copying a cryptographic key from said mass storage to ^^? cr A st( l ra ^ < l *?P at !P n \ . , . . 

• . , . * 134. A virtual distribution environment as in claim 133, 

said mam memory, «.*■*■*•■ * • 

, , . . , , . , . , said integrity value further comprising: 

deleunc said cryptographic key from said mass storage . . t . j * « i . 

6 T V-i ll .j . a cryptographic key used to encrypt or decrypt at least 

once said cryptographic key has been copied to main . - . ' . . l , , ., ~ 

J r some information generated by or used by said first 

memory, . 4 . A J J 

J host processing environment, 

using said cryptographic key to encrypt or decrypt 135 A distribution environment as in claim 134, 

information, 40 sa > ^ g^^d DOS t processing environment further compris- 

copying said cryptographic key from said main memory ing a secure storage location for cryptographic keys, 

to said mass storage, and ^jd insertion programming selecting said cryptographic 

deleting said cryptographic key from said main memory key from said secure storage location. 

once said cryptographic key has been copied to said ^ 136. A virtual distribution environment as in claim 133, 

mass storage, said insertion programming further comprising: 

whereby detection of said cryptographic key is rendered selection programming which selects at least one of said 

more difficult. multiplicity of software identifier storage locations and 

128. A method as in claim 127, further comprising the inserts said integrity value in said selected location or 
steps of: 5{) locations, but docs not insert said integrity value in 

following said deletion of said cryptographic key from non-selected locations. 

said mass storage, detecting a shutdown event, l^ 7 A virtual distribution environment as in claim 136, 

in response to said detection, transferring said crypto- ^ Programming further comprising: 

graphic key to said mass storage. programming which makes such selection on a random or 

129. A virtual distribution environment comprising 55 pseudo-random basis. 

n . . . - . - - 138. A virtual distribution environment as in claim 134, 

a first host processing environment comprising . , , . 4 . , r t , 

r *> t- & sai d second host processing environment further 

a central processing unit; comprising, 

main memory operatively connected to said central pro- location encryption programming containing program- 

cessing unit; ^ ming which records and encrypts the location of said 

mass storage operatively connected to said central pro- first software identifier storage location, 

cessing unit and said main memory; sa id encryption taking place using a location crypto- 

said mass storage storing tamper resistant software graphic key. 

designed to be loaded into said main memory and 139. A virtual distribution environment as in claim 138, 

executed by said central processing unit, said tamper 65 said first host processing environment further comprising 

resistant software comprising: one or more location cryptographic key storage loca- 

a multiplicity of software identifier storage locations, tions storing said location cryptographic key. 
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140. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 
comprising: 

a disk sector marked as damaged. 

141. A virtual distribution environment as in claim 139, 5 
said location cryptographic key storage location further 
comprising: 

a disk sector designated as an alternative disk sector to be 
used to replace disk sectors marked as damaged. 1Q 

142. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 
comprising: 

a disk sector normally reserved for non-general purpose 
use. 15 

143. A virtual distribution environment as in claim 142, 
said disk sector further comprising: 

a disk sector reserved for firmware storage. 

144. A virtual distribution environment as in claim 142, 
said disk sector further comprising: 20 

a disk sector reserved for storage of information generated 
during testing. 

145. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 
comprising: 25 

a storage location on a writeable, non-volatile semicon- 
ductor memory device, which storage location is nor- 
mally allocated for configuration data. 

146. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 30 
comprising: 

a storage location on a writeable, non-volatile semicon- 
ductor memory device, which storage location is nor- 
mally allocated for firmware. 35 

147. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 
comprising: 

a storage location on a writeable, non-volatile semicon- 
ductor memory device, which storage location is nor- 40 
mally allocated for BIOS. 

148. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 
comprising: 

one or more memory locations allocated by an operating 45 
system to a file, but not used by such file. 

149. A virtual distribution environment as in claim 148, 
said one or more memory locations further comprising: 

memory locations located after the end of said file but 
before the end of the memory sector allocated by said 50 
operating system to said file. 

150. A virtual distribution environment as in claim 149, 
said file further comprising a boot record. 

151. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 

comprising an unused storage location allocated to a 
file allocation map. 

152. A virtual distribution environment as in claim 139, 
said location cryptographic key storage location further 50 

comprising an unused storage location allocated to a 
directory. 

153. A virtual distribution environment as in claim 129, 
further comprising: 

one or more secure containers, comprising secure con- 65 
tents and one or more rules or controls governing the 
use of said secure contents. 
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154. A virtual distribution environment comprising 
a first host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory; 

said mass storage storing tamper resistant software 
designed to be loaded into said main memory and 
executed by said central processing unit, said tamper 
resistant software comprising: 

machine check programming which derives information 
from one or more aspects of said host processing 
environment, 

one or more storage locations storing said information 
said one or more storage locations including one or 
more memory locations allocated by an operating sys- 
tem to a boot record file, but not used by such file, said 
memory locations being located after the end of said 
file but before the end of the memory sector allocated 
by said operating system to said file, integrity program- 
ming which causes said machine check programming 
to derive said information, 

compares said information to information previously 
stored in said one or more storage locations, and 

generates an indication based on the result of said com- 
parison. 

155. A virtual distribution environment comprising 
a first host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory; 

said mass storage storing tamper resistant software 
designed to be loaded into said main memory and 
executed by said central processing unit, said tamper 
resistant software comprising: 

machine check programming which derives information 
from one or more aspects of said host processing 
environment, 

one or more storage locations storing said information; 
integrity programming which causes said machine 
check programming to derive said information, com- 
pares said information to information previously 
stored in said one or more storage locations, and 
generates an indication based on the result of said com- 
parison; and 

programming which takes one or more actions based on 

the state of said indication; 
said one or more actions including at least temporarily 

halting further processing. 

156. A virtual distribution environment comprising 
a first host processing environment comprising 

a central processing unit; 

main memory operatively connected to said central pro- 
cessing unit; 

mass storage operatively connected to said central pro- 
cessing unit and said main memory; 

said mass storage storing tamper resistant software 
designed to be loaded into said main memory and 
executed by said central processing unit, said tamper 
resistant software comprising: 
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machine check programming which derives information 159. A virtual distribution environment as in claim 158, 
from one or more aspects of said host processing said one or more aspects ofsaid database comprising data 
environment, regarding the last operation carried out on said data- 
one or more storage locations storing said information; base. 

integrity programming which 5 160. A virtual distribution environment as in claim 158, 

causes said machine check programming to derive said said one or more aspects of said database comprising data 

information, calculated based on the current state of said database, 

compares said information to information previously 161. A virtual distribution environment as in claim 158, at 

stored in said one or more storage locations, and least one of said storage locations further comprising: 

generates an indication based on the result of said 10 a disk sector marked as damaged. 

comparison; and 162. A virtual distribution environment as in claim 158, at 

programming which takes one or more actions based on least one of said storage locations further comprising: 

the state of said indication; a disk sector designated as an alternative disk sector to be 

said one or more actions including at least temporarily 15 used to replace disk sectors marked as damaged, 

disabling certain functions. 163. A virtual distribution environment as in claim 158, at 

157. A virtual distribution environment comprising least one of said storage locations further comprising: 

a first host processing environment comprising a disk sector normally reserved for non-general purpose 

a central processing unit; usc 

main memory operatively connected to said central pro- 20 164 A distribution environment as in claim 163, 

cessing unit- said disk sector further comprising: 

mass storage operatively connected to said central pro- a disk reserved for firmware storage. 

cessing unit and said main memory; 165 ; A distribution environment as in claim 163, 

. , „ 4 . • , . said disk sector further comprising: 

said mass storage storing tamper resistant software r to 

designed to be loaded into said main memory and 25 a disk sector reserved for storage of information generated 

executed by said central processing unit, said tamper during testing. 

resistant software comprising: 166 A virtual distribution environment as in claim 158, at 

, , u-i-i - - r 4- least one of said storage lwau^ns further comprising: 

machine check programming which denves information to r & 

from one or more aspects of said host processing ^ n a *<™& location on a writeable, non-volatile semicon- 
environment, one or more storage locations storing said 30 ductor memory device, which storage location is nor- 
information- mafly allocated for configuration data, 
integrity programming which causes said machine 167 A virtual distribution environment as in claim 158, at 
check progamming to derive said information com- lcast onc of ^ stora S c locations further comprising: 
pares said information to information previously a storage location on a writeable, non-volatile semicon- 
stored in said one or more storage locations, and ductor memory device, which storage location is re- 
generates an indication based on the result of said maU Y allocated for firmware. 

comparison; and 168. A virtual distribution environment as in claim 158, at 

programming which takes one or more actions based on least one of ^d storage locations further comprising: 

the state of said indication; « a borage location on a writeable, non-volatile semicon- 

said one or more actions including displaying a mes- ductor memory device, which storage location is nor- 

sage to the user. mall y allocated for BIOS. 

158. A virtual distribution environment comprising 169 A virtual distribution environment as in claim 158, at 

„ least one of said storage locations further comprising: 

a nrst host processing environment comprising & r ° 

a central processing unit' 45 one or more memorv ^cations allocated by an operating 

. / . . . . system to a file, but not used by such file. 

m ^ST3-° PCra Pl °" 170. A virtual distribution environment as in claim 169, at 

cessing urn , least one of said one or more memory locations further 

a database, comprising: 

said database being at least in part secure, memory locations located after the end of said file but 

mass storage operatively connected to said central pro- 50 Mom the end of the memory sector allocated by said 

cessing unit and said main memory; operating system to said file, 

said mass storage storing tamper resistant software 171. a virtual distribution environment as in claim 170, 

designed to be loaded into said main memory and said file comprising a boot record. 

executed by said central processing unit, said tamper ^ 172 A distribution environment as in claim 158, 

resistant software comprising: at , cast Qne ofaid storage locations fanner comprising an 

database check programming which derives information unused storage location allocated to a file allocation 

from one or more aspects of the state of said database, ma p 

one or more storage locations storing said information; 173. a virtual distribution environment as in claim 158, 

a °d 50 at lcast onc of said storage locations further comprising an 

integrity programming which unused storage location allocated to a directory, 

causes said database check programming to derive said 174. A virtual distribution environment as in claim 158, 

information, said virtual distribution environment further comprising 

compares said information to information previously programming which takes one or more actions based on 

stored in said one or more storage locations, and 65 the state of said indication, 

generates an indication based on the result of said com- 175. A virtual distribution environment as in claim 174 in 

parison. which 
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said one or more actions includes at least temporarily 
halting further processing. 

176. A virtual distribution environment as in claim 174 in 
which 

said one or more actions includes at least temporarily 
disabling certain functions. 

177. A virtual distribution environment as in claim 174 in 
which 

said one or more actions includes displaying a message to 
the user. 

178. A virtual distribution environment as in claim 174 in 
which 

said one or more actions includes initiating communica- 
tions with a trusted server. 

179. A virtual distribution environment as in claim 174 in 
which 

said one or more actions includes encrypting at least some 
information. 

180. A virtual distribution environment as in claim 174 in 
which 

said one or more actions includes deleting at least some 
information. 

181. A virtual distribution environment as in claim 180 in 
which 

said deleted information comprises at least one or more 
cryptographic keys. 

182. A virtual distribution environment as in claim 158, 
further comprising: 

one or more secure containers, comprising secure con- 
tents and one or more rules or controls governing the 
use of said secure contents. 

183. A method for protecting information from analysis or 
alteration, said method operating on a first host processing 
environment comprising a central processing unit, a main 
memory, one or more mass storage devices, and a secure 
database, said method comprising the following steps: 

deriving information from one or more aspects of said 

host processing environment on at least a first occasion, 
storing said information in a storage location, 
deriving said information from said one or more aspects 

of said host processing environment on at least a 

second occasion, 
comparing said information derived at least in part on said 

second occasion with said information stored in said 

storage location, 
if said comparison indicates that said information derived 

at least in part from said second occasion is different 

from said information stored in said storage location, 

setting an indicator, 
checking said indicator, and 

taking at least one action if said indicator is set said at 
least one action comprising halting processing. 

184. A virtual distribution environment comprising: 

a first host processing environment, said first host pro- 
cessing environment comprising a registry containing 
one or more installation keys; 

a second host processing environment comprising: 
a central processing unit; 

main memory operatively connected to said central 
processing unit mass storage operatively connected 
to said central processing unit and said main 
memory; 

a communications port; and 

secure software, said secure software including: 
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encrypted operational materials and installation materials, 

said installation materials including: 
encrypted installation materials, said encrypted installa- 
tion materials including: 
programming which causes at least certain portions of 
said operational materials to be decrypted, and con- 
founding algorithm programming which uses at least 
one confounding algorithm to create critical values 
required for correct operation of said operational mate- 
rials on said second host processing environment; at 
least one of said confounding algorithms constituting 
the MD5 algorithm, and 
unencrypted installation materials, said unencrypted 

installation materials including: 
programming which causes the decryption of said 

encrypted installation materials, 
programming which uses said communications port to 
establish communication with said first host processing 
environment, 

programming which includes a secure key exchange 
protocol, 

programming which receives an installation key from said 
registry, and 

programming which uses said installation key to decrypt 
at least a portion of said encrypted installation materi- 
als; 

whereby, said installation materials are decrypted and 
installed and cause said operational materials to be 
decrypted and installed. 
185. A virtual distribution environment comprising: 
a first host processing environment, said first host pro- 
cessing environment comprising a registry containing 
one or more installation keys; a second host processing 
environment comprising: 
a central processing unit; 
an operating system. 

main memory operatively connected to said central 

processing unit 
mass storage operatively connected to said central 

processing unit and said main memory; 
a communications port; and 
secure software, said secure software including: 
encrypted operational materials and installation 
materials said installation materials including: 
encrypted installation materials, said encrypted 
installation materials including: programming 
which causes at least certain portions of said 
operational materials to be decrypted, and con- 
founding algorithm programming which uses 
at least one confounding algorithm to create 
critical values required for correct operation of 
said operational materials on said second host 
processing environment; 
55 at least one of said confounding algorithms constituting the 
MD5 algorithm, and 

unencrypted installation materials, said unencrypted 
installation materials including: 
programming which causes the decryption of said 

encrypted installation materials, 
programming which uses said communications port to 
establish communication with said first host process- 
ing environment, 
programming which includes a secure key exchange 
protocol, 

programming which receives an installation key from 
said registry, and 
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programming which uses said installation key to 
decrypt at least a portion of said encrypted installa- 
tion materials; and 
one or more storage locations including one or more 
memory locations allocated by an operating system to a boot 
record file, but not used by such file said memory locations 
being located after the end of said file but before the end of 
the memory sector allocated by said operating system to said 
file, said one or more storage locations storing variables used 
as inputs to said confounding algorithm, said one or more 
storage locations including a storage location on a write able, 
non-volatile semiconductor memory device, which storage 
location is normally allocated for firmware; 
whereby, said installation materials are decrypted and 
installed and cause said operational materials to be 
decrypted and installed. 

186. A virtual distribution environment comprising 
a first host processing environment said first host pro- 
cessing environment comprising a registry containing 
one or more installation keys; 
a second host processing environment comprising: 
a central processing unit; 
a clock, 

main memory operatively connected to said central 
processing unit mass storage operatively connected 
to said central processing unit and said main 
memory; 
a communications port; and 
secure software, said secure software including: 

encrypted operational materials and installation materials, 
said installation materials including: 

encrypted installation materials, said encrypted installa- 
tion materials comprising. 

programming which causes at least certain portions of 
said operational materials to be decrypted, and trusted 
server time programming comprising programming 
which controls said communications port to contact a 
trusted server and programming which obtains a time 
value from said trusted server, and clock initialization 
programming which synchronizes said clock to said 
time value obtained from said trusted value, said clock 
initialization programming determining whether said 
time value specified by said clock is the same or within 
a specified range as the time value obtained from said 
trusted server, if said determination results in an affir- 
mative conclusion, said clock initialization program- 
ming setting an indication indicating that said clock has 
been synchronized with said time value obtained from 
said trusted server, and if said determination results in 
a negative conclusion, said clock initialization pro- 
gramming performing at least one of the following 
actions: 

setting said time value specified by said clock to be the 
same as or within a specified range of the time value 
obtained from said trusted server, or storing a time 
offset value indicating the difference between said time 
value specified by said clock and the time value 
obtained from said trusted server; and 
unencrypted installation materials said unencrypted 
installation materials including: 
programming which causes the decryption of said 

encrypted installation materials 
programming which uses said communications port to 
establish communication with said first host process- 
ing environment, 
programming which includes a secure key exchange 
protocol, 
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programming which receives an installation key from 
said registry, and 

programming which uses said installation key to 
decrypt at least a portion of said encrypted installa- 
tion materials; 
whereby, said installation materials are decrypted and 

installed and cause said operational materials to be 

decrypted and installed. 

187. A virtual distribution environment as in claim 186, 
said first host processing environment further comprising: 

an execution timing data storage location, 

execution timing integrity circuitry, 

said execution timing integrity circuitry operatively con- 
nected to said clock and to said execution timing data 
storage location, 

said execution timing circuitry including circuitry causing 
a designated program routine to execute, said circuitry 
further causing information relating to the duration of 
said execution to be stored in said execution timing 
data storage location; 

said encrypted portion of said installation materials fur- 
ther comprising: 

programming causing said execution timing integrity cir- 
cuitry to operate using one or more program routines 
contained in said operational materials. 

188. A method for installing protected software on a host 
processing environment, said method comprising the fol- 
lowing steps: 

generating installation programming comprising a stub 

portion and a non-stub portion; 
encrypting said non-stub portion of said installation 

programming, 
generating operational programming, 
encrypting said operational programming, 
communicating said installation programming and said 

operational programming to said host processing 

environment, 

said host processing environment executing programming 
contained in said stub portion of said installation 
programming, 

said programming contained in said stub portion of said 
installation programming causing said host processing 
environment to initiate communications with a remote 
trusted server, 

said remote trusted server providing a cryptographic key 
to said host processing environment, 

said host processing environment using said crypto- 
graphic key to decrypt said non-stub portion of said 
installation programming, 

said host processing environment executing programming 
contained in said non-stub portion of said installation 
programming, 

said programming contained in said non-stub portion of 
said installation programming causing said host pro- 
cessing environment to undertake one or more actions 
designed to render said operational programming more 
secure, 

following said one or more actions, said host processing 
environment installing said operational programming. 

189. A method as in claim 188, said one or more actions 
further comprising the following steps: 

executing one or more operations, 
storing the time taken for execution of said one or more 
operations in a secure location. 
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190. A method as in claim 189, 

said one or more operations comprising operations carried 
out by programming contained within said operational 
programming. 

191. A method as in claim 188, said one or more actions 
further comprising: 

storing one or more cryptographic keys in a secure 
location. 

192. A method as in claim 188, said one or more actions 
further comprising: 

evaluating at least one aspect of said host processing 

environment, and 
storing the results of such evaluation in a secure location. 

193. A method as in claim 192, 

said at least one aspect of said host processing environ- 
ment comprising data regarding disk defects. 

194. A method as in claim 192, 

said at least one aspect of said host processing environ- 
ment comprising data regarding one or more addresses. 

195. A method as in claim 194, 

said one or more addresses comprising network 
addresses. 

196. A method as in claim 195, 

said network comprising an Ethernet network. 

197. A method as in claim 188, said one or more actions 
further comprising: 

decrypting at least a portion of said operational 
programming, and 

altering at least one aspect of said operational program- 
ming. 

198. A method as in claim 197, 

said step of altering further comprising: 
selecting said aspect for alteration from among a multi- 
plicity of possible aspects. 

199. A method as in claim 198 

said step of selecting being based on information gener- 
ated in a random or pseudo-random manner. 

200. A method as in claim 197, 

said step of altering further comprising, 
inserting at least one value in said operational program- 
ming. 

201. A method as in claim 200, 

said step of altering further comprising, 
generating said value in a random or pseudo-random 
manner. 

202. A method as in claim 197, 

said step of altering further comprising, 
inserting at least one program sequence into said opera- 
tional programming. 

203. A method as in claim 202, 

said step of altering further comprising, 
selecting a location for such insertion from among a 
plurality of locations. 

204. A method as in claim 203, 

said step of selecting further comprising, 
choosing among said plurality of locations in a random or 
pseudo-random manner. 

205. A method as in claim 202, 

said program sequence being a program sequence which 
has no effect if executed. 

206. A method as in claim 202, 

said program sequence being a program sequence which 
sets an indicator if executed. 
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207. A method as in claim 202, 

said program sequence being a program sequence which 
erases certain information if executed. 

208. A method as in claim 207, 

5 said erased information comprising one or more crypto- 
graphic keys. 

209. A method as in claim 202, 

said program sequence being a program sequence which 
1Q terminates processing if executed. 

210. A virtual distribution environment comprising: 
an appliance comprising: 

a central processing unit, 

an appliance memory, said appliance memory containing 
15 decryption programming; 

an appliance communications port for communicating 
said decryption programming from said appliance 
memory to a memory of an associated printer, 
a printer comprising 
20 a printer communications port operationally connected to 
said appliance communications port, 
a microcontroller, and 

said printer memory containing decryption programming, 
25 said decryption program received from said appliance 
memory through said appliance communications port 
and said printer communications port; and 
said decryption programming being used for the decryp- 
tion of files received from said appliance through said 
30 appliance communications port and said printer com- 
munications port. 

211. A virtual distribution environment as in claim 210, 
said decryption programming comprising program state- 
ments written in a printer control language. 

35 212. A virtual distribution environment as in claim 211, 
said printer control language constituting PostScript. 

213. A virtual distribution environment as in claim 211, 
said appliance further comprising encryption circuitry 

operationally connected to encrypt files sent to said 
printer through said appliance communications port. 

214. A virtual distribution environment as in claim 211, 
said printer further comprising means for locking said 

decryption programming in said printer memory. 
45 215. A method of printing comprising the steps of: 

downloading a decryption program from a memory of an 

appliance to a memory of an attached printer, 
encrypting a file to be printed, 

downloading said encrypted file from said memory of said 
50 appliance to said memory of said attached printer, 
said attached printer using said decryption program to 

decrypt said file, 
said attached printer printing said file. 
216. A method of printing as in claim 215, comprising the 
55 following additional step: 

following said step of decrypting said file, said attached 
printer deleting said decryption program from said 
memory of said attached printer. 
6Q 217. A method of printing comprising the steps of: 

downloading a fingerprinting program from a memory of 
an appliance to a memory of an attached printer, said 
fingerprinting program including a fingerprinting key, 
downloading at least two fonts from said memory of said 
65 appliance to said memory of said attached printer 

downloading a file to be printed from said memory of said 
appliance to said memory of said attached printer, 
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said printer executing said fingerprinting program, said 
execution comprising the following steps: 

using said fingerprinting key to select among said fonts, 

applying at least two of said fonts to said file in accor- 
dance with said fingerprinting key, and 5 

printing said file using said fonts, 

whereby, said fonts constitute a fingerprint embedded in 
said printed file. 

218. A method of printing as in claim 2li, 10 
said step of using said fingerprinting key to select among 

said fonts including selecting at least two fonts which 
arc closely related, 
said step of applying at least two of said fonts to said file 
including applying said at least two fonts which are 15 
closely related. 

219. A method of secure printing comprising the follow- 
ing steps: 

generating a scrambled font set, said generating step 
comprising the following steps: 20 

downloading a standard font comprising a set of charac- 
ters and command codes, said command codes related 
to specific characters, 

altering the relationship of characters to command codes 25 
in accordance with a specified formula, 

downloading said scrambled font set to a printer, infor- 
mation to be printed, 

downloading said print file to said printer, 

said printer using said scrambled font set to print a 30 
document based on said print file, 

whereby at least a portion of said document is printed in 
useable form on a printer containing said scrambled 
font set, but said portion is printed in a less useable or 3S 
non-useable form on a printer not containing a 
scrambled font set but instead containing said standard 
font set. 
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220. A virtual distribution environment comprising: 
a first host processing environment comprising: 
an operating system, 
a central processing unit; 

one or more storage locations including one or more 
memory locations allocated by an operating system to 
a boot record file, but not used by such file, said 
memory locations being located after the end of said 
file but before the end of the memory sector allocated 
by said operating system to said file, said one or more 
storage locations storing cryptographic keys, 
said one or more storage locations including a storage 
location on a writeable, non-volatile semiconductor 
memory device, which storage location is normally 
allocated for firmware; 

main memory operatively connected to said central pro- 
cessing unit mass storage operatively connected to said 
central processing unit and said main memory; 

a communications port; and 

secure software, said secure software including: 

encrypted operational materials and installation materials, 
said installation materials including: 

encrypted installation materials, said encrypted installa- 
tion materials including: 

programming which causes at least certain portions of 
said operational materials to be decrypted, and 

unencrypted installation materials, said unencrypted 
installation materials including: 

programming which causes the decryption of said 
encrypted installation materials, whereby, said instal- 
lation materials are decrypted and installed and cause 
said operational materials to be decrypted and installed. 

***** 



